RaaS (Ransomware as a Service) Nedir? Ekosistemi, Tarihi, Gerçek Vakalar ve Savunma Rehberi

RaaS (Ransomware as a Service) Nedir? Ekosistemi, Tarihi, Gerçek Vakalar ve Savunma Rehberi

Kısa cevap: RaaS, fidye yazılımı ile gasp operasyonunda kullanılan bazı araç ve hizmetlerin operatörler tarafından bağlı kuruluşlara sunulduğu suç modelidir. Operatör platformu veya teknik altyapıyı sağlar; bağlı kuruluşlar hedefe erişimi elde eder ya da satın alır ve olayın saha kısmını yürütür. Bu iş bölümü, ransomware saldırılarının daha fazla aktör tarafından, daha geniş ölçekte ve farklı markalar altında tekrarlanabilmesini sağlar. S01

Bu kapsamlı rehber; RaaS'ın tanımını, tarihini ve yeraltı ekonomisini açıklarken gerçek vakaları, erken uyarı işaretlerini, savunma kontrollerini ve olay sonrası kararları aynı kanıt zinciri içinde ele alır. Genel siber güvenlik konuları yalnızca RaaS riskini anlamak veya azaltmak için gerekli olduğu ölçüde açıklanır.

Yayıncı: BilişimTürk
İlk yayın ve son güncelleme: 22 Temmuz 2026
Araştırma kesim tarihi: 22 Temmuz 2026
Sürüm: 1.0

Savunma amaçlı yayın: Bu içerik risk yönetimi, olay müdahalesi ve güvenlik farkındalığı amacıyla hazırlanmıştır. Yetkisiz erişim, zararlı yazılım geliştirme, veri sızdırma veya fidye operasyonu yürütmeye yarayan uygulanabilir talimatlar içermez.

Öne çıkan noktalar

• RaaS yalnızca bir zararlı yazılım türü değil; operatör, bağlı kuruluş, ilk erişim aracısı, barındırma, veri sızıntısı ve ödeme rollerini birleştirebilen bir suç hizmetleri ekosistemidir.
• Modern RaaS olaylarında şifreleme tek baskı aracı değildir. Veri hırsızlığı, yayın tehdidi, müşteri baskısı ve hizmet kesintisi birlikte veya ayrı ayrı kullanılabilir.
• Bir grubun altyapısının bozulması tehdidi azaltabilir; fakat kod, erişim, bağlı kuruluşlar ve uzmanlık başka markalara taşınabildiği için kurum savunması tek bir grup adına bağlanmamalıdır.
• En etkili savunma; güçlü kimlik, ayrıcalık ayrımı, ağ segmentasyonu, davranış görünürlüğü, değiştirilemez yedek, temiz kurtarma ve iş sürekliliğini birlikte kurar.
• Fidye ödemesi verinin silindiğini, tüm sistemlerin geri döneceğini veya olayın hukuki ve operasyonel sonuçlarının sona ereceğini garanti etmez.
• Grup durumları, olay sayıları ve zarar rakamları kaynak türü ile kesim tarihine göre okunmalıdır; sızıntı sitesi iddiası tek başına doğrulanmış vaka değildir.

İçindekiler

1. Yayın kapsamı, güvenlik sınırı ve kanıt yöntemi
2. RaaS'a giriş
3. RaaS tarihi
4. RaaS ekonomisi
5. Bir RaaS operasyonu nasıl işler?
6. RaaS grupları ve markaları
7. Dünyayı değiştiren büyük RaaS olayları
8. RaaS'ın hedef aldığı kurumlar
9. Erken uyarı işaretleri
10. RaaS'a karşı savunma
11. Olay sonrası yapılması gerekenler
12. RaaS terimleri sözlüğü
13. RaaS hakkında sık sorulan sorular
14. RaaS hakkında yanlış bilinenler
15. Güncelleme ve düzeltme politikası
16. Kaynakça ve kanıt kayıtları

Yayın kapsamı, güvenlik sınırı ve kanıt yöntemi

Bu rehberin amacı

Bu çalışma, Ransomware as a Service (RaaS) tehdidini yalnızca “dosyaları şifreleyen zararlı yazılım” düzeyinde değil; geliştirici, operatör, bağlı kuruluş, ilk erişim aracısı, veri sızıntısı, pazarlık, ödeme ve yeniden yapılanma katmanları olan bir suç hizmetleri ekosistemi olarak açıklar. Odak, okuyucunun saldırı zincirini erken görmesi, kontrolleri doğru noktaya yerleştirmesi, olay sırasında karar verebilmesi ve iş sürekliliğini koruyabilmesidir.

Bu rehberde genel siber güvenlik kavramları ancak RaaS riskini açıklamak için gerektiği ölçüde ele alınır. Örneğin MFA, kendi başına bir kimlik güvenliği dersi olarak değil; çalınmış veya satın alınmış hesabın RaaS operasyonuna dönüşmesini engelleyen bir kontrol olarak incelenir. Yedekleme, yalnızca veri koruma konusu olarak değil; saldırganın şifreleme ve silme yoluyla kurduğu baskıyı azaltan bir dayanıklılık mekanizması olarak değerlendirilir.

Güvenli yayın sınırı

Savunma ilkesi: Metin, saldırı gerçekleştirmeyi öğretmez. Çalışır komutlar, zararlı kod, yükleyici/payload geliştirme, erişim kalıcılığı tarifi, canlı sızıntı sitesi adresi, kripto cüzdanı, ödeme gizleme yöntemi, kimlik bilgisi ele geçirme yöntemi veya pazarlık manipülasyonu sunulmaz. Operasyon akışı; yalnızca amaç, savunmacının görebileceği işaret ve riski azaltan kontrol düzeyinde anlatılır.

Bu sınır, tarihsel ve güncel vakaların eksik anlatıldığı anlamına gelmez. Tam tersine, karar vericinin ihtiyaç duyduğu etkiler, doğrulanmış atıflar, iş kaybı, hizmet kesintisi, yönetişim hataları, tespit fırsatları ve iyileştirme dersleri ayrıntılı biçimde ele alınır.

Araştırma kesim tarihi ve güncellik

Grup durumları, istatistikler ve güncel tehdit değerlendirmeleri için kesim tarihi 22 Temmuz 2026'dır. RaaS markaları hızla kapanır, bölünür, yeniden adlandırılır veya bağlı kuruluşlarını başka yapılara kaptırır. Bu nedenle “aktif”, “bozulmuş”, “markası kapanmış” ve “devamlılığı belirsiz” etiketleri sabit kimlikler değil, kesim tarihindeki kanıt durumudur.

Kaynak hiyerarşisi

1. A düzeyi: Resmî kurum, kolluk/yargı kaydı, düzenleyici bildirim, mağdur kurumun birincil açıklaması veya nihai standart.
2. B düzeyi: Çok taraflı kurum raporu veya yöntemini açıklayan akademik çalışma.
3. C düzeyi: Olay müdahale şirketi ya da sektör araştırması. Yalnızca güncel saha gözlemi için ve veri sınırlılığı belirtilerek kullanılır.

Sızıntı sitelerindeki “mağdur” listeleri doğrulanmış olay sayısı değildir. Aynı kuruluş birden çok kez yazılabilir, olay tarihi ile yayın tarihi karışabilir, müzakere baskısı için yanlış ya da eksik kayıt üretilebilir ve şifreleme gerçekleşmeden yalnızca veri hırsızlığı yaşanmış olabilir. Bu nedenle sektör raporlarındaki sızıntı sitesi istatistikleri eğilim göstergesi olarak kullanılır; kesin adli sayım olarak sunulmaz. S13 S16

Atıf güveni ve dil standardı

Sayılar nasıl okunmalı?

FBI'nin 2025 Internet Crime Report verisi 3.600'den fazla ransomware şikâyeti ve 32 milyon ABD dolarını aşan bildirilen kayıp gösterir; ancak hem bildirim eksikliği hem de “kayıp” tanımının fidye, kesinti, kurtarma ve üçüncü taraf zararlarını tam yakalamaması nedeniyle bu rakam gerçek ekonomik etkinin alt sınırıdır. Aynı rapor 63 yeni varyant görüldüğünü ve öne çıkan adlar arasında Akira, Qilin, Play, RansomHub, LockBit, DragonForce ve Medusa'nın bulunduğunu belirtir. S10

ENISA'nın 2025 görünümü, Temmuz 2024–Haziran 2025 arasında analiz edilen 4.875 olayı Avrupa tehdit bağlamına yerleştirir; INTERPOL'ün 2026 değerlendirmesi ise suç altyapısının ve fidye odaklı faaliyetlerin sınır aşan niteliğini Asya–Pasifik örnekleriyle gösterir. Bu kurumların örneklem ve coğrafyaları farklı olduğundan sayılar birleştirilmez. S09 S12

Bu rehberde finansal rakamlar mümkün olduğunda düzenleyici mali bildirimlerden alınır. Doğrudan olay müdahale maliyeti, gelir kaybı, iş kesintisi, müşteri desteği, hukuki karşılık ve ekonomik tahmin birbirine eklenmez; aynı zararın iki kez sayılması önlenir.

Okuyucu profili

• Yönetim kurulu ve üst yönetim: Ekosistemin iş riskini, karar haklarını ve yatırım önceliklerini görür.
• Bilgi işlem ve güvenlik ekipleri: Erken işaretleri, kontrol hedeflerini ve müdahale zaman çizelgesini kullanır.
• Hukuk, uyum, iletişim ve insan kaynakları: Delil koruma, bildirim, çalışan/mağdur iletişimi ve kriz yönetişimi sınırlarını görür.
• KOBİ ve ev kullanıcıları: Kurumsal kontrollerin uygulanabilir karşılıklarını ve minimum dayanıklılık tabanını öğrenir.
• Öğrenciler ve araştırmacılar: Kaynak derecelendirmesiyle grup ve vaka iddialarını birbirinden ayırır.

Rehberin altın kuralı

Bu rehberde yer alan her bölüm doğrudan RaaS ile ilişkilidir. RaaS'ı anlamaya katkı sağlamayan genel siber güvenlik konularına girilmez. Genel kavramlar yalnızca RaaS bağlamını açıklamak için gerekli olduğu ölçüde ele alınır. Her bölümün sonunda “RaaS açısından neden önemli?” değerlendirmesi yer alır.

Bu yayın notu RaaS'ı anlamaya nasıl katkı sağlar?

RaaS araştırmasında marka iddiası, adli doğrulama ve ekonomik tahmin kolayca birbirine karışır. Bu yayın notu; rehberin saldırı öğretmeyen savunma sınırını, kanıt derecelerini ve kesim tarihini sabitleyerek sonraki tüm bölümlerin güvenilir ve karşılaştırılabilir okunmasını sağlar.

RaaS'a Giriş

RaaS nedir?

RaaS, fidye yazılımı ve buna eşlik eden suç hizmetlerinin, bir veya daha çok operatör tarafından bağlı kuruluşlara sunulduğu iş modelidir. Operatör; şifreleme yazılımı, yönetim paneli, mağdur iletişim altyapısı, veri yayımlama kanalı, ödeme takibi veya “destek” gibi bileşenlerden bazılarını sağlar. Bağlı kuruluş ise hedefe erişimi elde eder ya da satın alır, saldırı hazırlığını yürütür ve gasp sürecini işletir. Her marka aynı hizmet paketini sunmaz; bazıları tam platform, bazıları yalnızca yazılım, bazıları ise gevşek bir suç ortaklığıdır. S01

RaaS'ı yalnızca zararlı yazılım ailesi olarak görmek üç nedenle yanıltıcıdır. Birincisi, aynı şifreleyici birbirinden bağımsız bağlı kuruluşlarca farklı hedeflerde kullanılabilir. İkincisi, aynı bağlı kuruluş marka değiştirerek başka bir RaaS programına geçebilir. Üçüncüsü, güncel olayların bir bölümünde şifreleme hiç yapılmadan yalnızca veri hırsızlığı ve yayın tehdidiyle gasp yürütülür. Bu nedenle savunma, dosya uzantısı veya tek bir imza yerine kimlik, erişim, davranış, veri hareketi ve kurtarma bütünlüğünü birlikte ele almalıdır. S01 S13

RaaS neden ortaya çıktı?

RaaS, suç ekonomisinde uzmanlaşma ve ölçek arayışının ürünüdür. Her aktörün aynı anda yazılım geliştirme, açık arama, hedefe erişme, ağ içinde ilerleme, veri toplama, ödeme alma ve operasyon güvenliği konusunda uzman olması gerekmez. Görevlerin bölünmesi, teknik yeteneği sınırlı fakat erişim veya sosyal mühendislik becerisi olan kişilerin de büyük ölçekli gaspa katılmasını kolaylaştırdı.

Modelin ortaya çıkmasını destekleyen başlıca koşullar şunlardır:

• Kripto varlıkların sınır ötesi ödemeyi kolaylaştırması; buna karşın kamuya açık zincirlerin kolluk ve araştırmacılar için iz bırakması.
• Anonimleştirici altyapılar ve kötüye kullanılan barındırma hizmetlerinin suç pazarlarına küresel erişim sağlaması.
• İnternete açık hizmetlerin, uzaktan erişimin ve tedarik zincirlerinin yaygınlaşması.
• Çalınmış kimlik bilgisi, ilk erişim, spam dağıtımı ve veri yayımlama gibi tamamlayıcı suç hizmetlerinin olgunlaşması.
• Büyük kuruluşlarda kesinti maliyetinin yüksek, toparlanma süresinin uzun ve hassas veri baskısının güçlü olması.

NCSC, ransomware olayının tek bir “çete” tarafından uçtan uca yürütüldüğü varsayımının çoğu zaman yanlış olduğunu; erişim sağlayıcıları, platformlar, bağlı kuruluşlar ve diğer kolaylaştırıcıların birlikte çalıştığı bir ekosistem bulunduğunu vurgular. S01

Neden bu kadar hızlı yayıldı?

RaaS'ın büyümesi teknolojik yenilikten çok üretim hattı mantığıyla açıklanabilir. Bir operatörün yazılım ve gasp altyapısını tekrar tekrar kullanması marjinal maliyeti düşürür. Bağlı kuruluşlar farklı sektör, ülke ve erişim yöntemlerine yönelerek operatörün erişimini genişletir. Başarılı bir bağlı kuruluşun başka markaya geçmesi kolaydır; kolluk operasyonuyla bir markanın kapanması, insan sermayesinin tamamının ortadan kalktığı anlamına gelmez.

Yayılmayı hızlandıran diğer etkenler şunlardır:

• Tekrarlanabilirlik: Aynı panel, fidye notu mantığı, veri yayın süreci ve gelir paylaşımı çok sayıda olayda kullanılabilir.
• Giriş engelinin düşmesi: Saldırganın şifreleyici geliştirmesi gerekmez; erişim veya insan manipülasyonu gibi başka bir uzmanlığı paraya çevirebilir.
• Yüksek baskı: Şifreleme, veri sızıntısı, müşteri/çalışan iletişimi ve hizmet kesintisi aynı anda kullanılabilir.
• Tedarik zinciri etkisi: Tek bir yönetim yazılımı, hizmet sağlayıcı veya kimlik sistemi üzerinden çok sayıda alt kuruma ulaşılabilir.
• Marka dayanıklılığı: Altyapı bozma operasyonları riski artırsa da bağlı kuruluşlar, erişim aracılarının ve geliştiricilerin başka programlara kayması tehdidi sürdürür. S11

Klasik ransomware ile farkı

“Klasik” ve “RaaS” kesin iki kutup değildir. Tekil aktör kiralanmış altyapı kullanabilir; bir RaaS markası kapalı bir çekirdek ekibe dönüşebilir; veri hırsızlığı yapan bir grup şifreleyici kullanmayabilir. Bu rehberde RaaS, teknik ürün kadar ekonomik ve örgütsel model olarak ele alınır.

SaaS mantığıyla benzerlikleri

RaaS terimindeki “as a Service”, yasal SaaS işletmelerinin meşruluğunu değil, tekrarlanabilir hizmet mantığını anlatan bir benzetmedir:

• Operatör ortak bir ürün ve altyapıyı çok sayıda kullanıcıya sunar.
• Güncelleme, kullanıcı yönetimi, gösterge paneli ve destek gibi merkezi işlevler bulunabilir.
• Gelir abonelik, sabit ücret, komisyon veya gelir paylaşımına bağlanabilir.
• Kullanıcı/bağlı kuruluş edinimi, itibar ve ödeme disiplini programın büyümesini etkiler.
• Hizmet sağlayıcı ile saha uygulayıcısı arasında rol ayrımı oluşur.

SaaS benzetmesinin sınırları

RaaS'ı “suç dünyasının SaaS'ı” diye kısaltmak öğretici olsa da dört önemli farkı gizleyebilir. Birincisi, sözleşme ve tüketici koruması yerine tehdit, dolandırıcılık ve karşılıklı güvensizlik vardır. İkincisi, marka adları gerçek örgütsel sürekliliği kanıtlamaz. Üçüncüsü, bağlı kuruluşlar birden çok programa geçebilir ve operatörler “çıkış dolandırıcılığı” yapabilir. Dördüncüsü, platformun başarısı mağdurun zararına ve hukuka aykırı eyleme dayanır. Bu nedenle meşru iş terminolojisi, yapıyı anlamak için kullanılır; failleri profesyonelleştiren veya öven bir dil olarak kullanılmaz.

RaaS olayında ne korunur?

Bir kurum yalnızca dosyalarını değil, şu altı değeri korur:

1. Kimlik güveni: Hesabın gerçekten yetkili kişi tarafından kullanıldığına güvenebilmek.
2. Yönetim düzlemi: Dizin, yedek, sanallaştırma, bulut, RMM ve güvenlik konsollarını ayrıcalıklı kötüye kullanımdan korumak.
3. Veri gizliliği: Şifreleme olmasa bile veri sızıntısı ve gasp baskısını azaltmak.
4. Hizmet sürekliliği: Klinik, üretim, ödeme, lojistik veya kamu hizmetini güvenli şekilde sürdürebilmek.
5. Delil ve günlük bütünlüğü: Olayı anlamak, kapsamı belirlemek ve hukuki yükümlülükleri yerine getirmek.
6. Kurtarma güveni: Yedeklerin temiz, erişilebilir ve saldırgan kontrolünden bağımsız olduğundan emin olmak.

Yönetim için beş temel soru

• RaaS riski hangi kritik hizmeti durdurursa kurumun karar süresi saatlerle ölçülür?
• İnternete açık hizmet ve ayrıcalıklı hesap envanteri güncel mi?
• Bir kimlik ihlali, yedek veya sanallaştırma yönetimine doğrudan ulaşabilir mi?
• Yedekten geri dönüş son kez ne zaman, hangi süre ve veri kaybıyla gerçekten test edildi?
• Olay anında teknik izolasyon, hukuki bildirim, kamu iletişimi ve iş sürekliliği kararlarını kim verir?

RaaS açısından neden önemli?

Bu bölüm RaaS'ı bir zararlı yazılım dosyasından ayırıp hizmet, gelir paylaşımı ve uzmanlaşma ekosistemi olarak tanımlar. Bu bakış olmadan kurum yalnızca son aşamadaki şifrelemeye yatırım yapar; oysa erişim, kimlik, veri sızıntısı, yönetim düzlemi ve kurtarma baskısı daha önce başlar.

RaaS Tarihi

Tarihi okurken kaçınılması gereken hata

Ransomware tarihi ile RaaS tarihi aynı şey değildir. Erken fidye yazılımları ödeme talep eden tekil programlardı; RaaS ise geliştirici/operatör ile saldırıyı yürüten bağlı kuruluş arasında tekrarlanabilir hizmet ve gelir paylaşımını ifade eder. “İlk RaaS” etiketi, yeraltı forum kayıtlarının eksikliği ve pazarlama iddiaları nedeniyle tartışmalıdır. Bu rehber Tox ve Cerber gibi adları “yaygın biçimde anılan erken örnekler” olarak kullanır; kesin bir mucit ilan etmez. S63

Dönemlere göre gelişim

İlk fidye yazılımlarından ölçekli şifrelemeye

Erken dönem fidye yazılımları fiziksel dağıtım, basit kilitleme veya yerel ödeme yöntemleriyle sınırlıydı. İnternetin, otomatik dağıtımın, güçlü kriptografinin ve dijital ödemelerin birleşmesi saldırganın coğrafi sınırını küçülttü. CryptoLocker'ın 2013–2014 dönemindeki etkisi, şifreleme ile ödeme baskısının kitlesel dağıtımla ne kadar ölçeklenebileceğini gösterdi. 2014'teki çok uluslu Gameover Zeus/CryptoLocker operasyonu ise altyapı ve para akışına yönelik eşgüdümlü müdahalenin erken örneklerinden oldu. S24

Bu evre henüz bugünkü anlamıyla olgun RaaS değildi. Ancak iki ekonomik ders oluştu: başarılı şifreleme tekrar kullanılabilir bir ürüne dönüştürülebilir ve dağıtım ağı yazılım geliştiriciden ayrılabilir.

RaaS modelinin belirginleşmesi: 2015–2018

2015–2016 döneminde yeraltı pazarlarında kullanıma hazır ransomware paketleri ve gelir paylaşımıyla çalışan programlar görünür hâle geldi. Europol, 2016 tehdit değerlendirmesinde ransomware'ın kolluk açısından öne çıkan zararlı yazılım tehdidine dönüştüğünü kaydetti. S25 Bu dönemde “kolay panel”, “otomatik ödeme” ve “kişiselleştirme” gibi suç pazarlaması söylemleri, saldırı kapasitesinin ürünleştirildiğini gösteriyordu.

Savunma açısından kritik değişim, zararlı yazılımın tek bir fail imzası olmaktan çıkmasıydı. Aynı aile farklı erişim yöntemleri ve farklı operasyon kalitesiyle görülebilir; bu da yalnızca dosya imzasına dayanan korumayı zayıflatır.

Çift gasp ve büyük av: 2019–2020

Kurumlar çevrimdışı yedeklemeyi geliştirdikçe saldırganlar ödeme baskısını yeniden tasarladı. Veri önce dışarı çıkarılıyor, ardından şifreleniyor ve ödeme yapılmazsa yayımlanacağı söyleniyordu. Çift gasp, “yedekten döneriz” cevabını tek başına yetersiz bıraktı. Hasta kaydı, kimlik belgesi, fikrî mülkiyet, sözleşme veya çalışan verisi; şifreleme olmasa bile krize dönüşebilir.

“Big-game hunting”, çok sayıda küçük kurban yerine yüksek kesinti maliyeti olan kurumları seçme eğilimiydi. Bu yaklaşım bağlı kuruluşların kurumsal ağlarda daha uzun kalmasını, erişim satın almasını ve pazarlık baskısını hedefin ödeme kapasitesine göre ayarlamasını teşvik etti. RaaS bu uzmanlaşmayı ölçekleyen platform rolünü üstlendi. S01

2021: kritik altyapı ve tedarik zinciri yılı

Colonial Pipeline olayında iş ağı etkilenince boru hattı operasyonları önlem olarak durduruldu; yakıt tedarikindeki bozulma RaaS'ın fiziksel dünyaya etkisini görünür kıldı. JBS olayı gıda üretiminde kesinti yarattı. Kaseya VSA olayı ise tek bir teknoloji/hizmet sağlayıcısının çok sayıdaki alt müşteriyi nasıl etkileyebileceğini gösterdi. S40 S42 S44

Bu üç olay aynı saldırı tekniğini öğretmez; aynı yönetim dersini öğretir: kritik hizmetin dijital bağımlılık haritası, üçüncü taraf erişimi ve manuel çalışma modu önceden bilinmiyorsa teknik olay hızla ekonomik veya toplumsal krize dönüşür.

2022–2024: parçalanma, veri odaklı gasp ve kimlik krizi

Conti'nin marka olarak sona ermesi, geçmiş bağlı kuruluşların ve uzmanların tamamen ortadan kalktığı anlamına gelmedi. Costa Rica vakası, kamu gelir toplama ve sosyal hizmet altyapısının uzun süreli kesintisini gösterdi. S56 2023'te Cl0p'un MOVEit üzerinden yürüttüğü kitlesel veri hırsızlığı, şifreleme yapılmadan da geniş ölçekte gasp kurulabileceğini kanıtladı. S31

2023 Las Vegas olayları, yardım masası ve kimlik doğrulama süreçlerinin yönetim düzlemine açılan kapı olabileceğini gösterdi. MGM ve Caesars aynı şehir ve dönemde anılsa da ayrı olaylardır; tek bir “Las Vegas saldırısı” olarak birleştirilmemelidir. S46 S47 S61

2024'te LockBit ve ALPHV altyapılarına yönelik kolluk müdahaleleri marka güvenini ve operasyon kapasitesini sarstı. Fakat aynı yıl Change Healthcare, CDK Global ve Synnovis gibi hizmet yoğun kurumlar üzerinden çok büyük zincirleme etkiler yaşandı. Marka bozma, savunma başarısıdır; fakat erişim aracıları, bağlı kuruluşlar ve yeni platformlar kaldığı sürece tehdidi tek başına bitirmez. S11 S28

2025–2026: modern RaaS'ın durumu

FBI'nin 2025 verisi, tek bir grubun tartışmasız hâkimiyetinden çok çeşitlenen varyant ve markaları gösterir. Akira şikâyetlerde üst sıradadır; Qilin, Play, RansomHub, LockBit, DragonForce, SafePay ve Medusa gibi adlar görünürdür. Ancak şikâyet sayısı ile küresel gerçek olay sayısı aynı değildir. S10

Olay müdahale gözlemleri 2025'te araştırılan olayların büyük bölümünde doğrulanmış veya şüpheli veri hırsızlığı bulunduğunu; sanallaştırma altyapısının da dikkat çekici bir hedefe dönüştüğünü bildirir. Bu, şifreleyicinin uç noktadan önce yedek, bulut ve hipervizör yönetim düzlemine uzanan kimlik zincirinin korunması gerektiği anlamına gelir. Bu oranlar tek bir sağlayıcının müşteri kümesine aittir; dünya geneline doğrudan genellenmez. S13

Yardım masası üzerinden kimlik manipülasyonundan vSphere yönetim katmanına uzanan 2025 saha araştırması da, hipervizörü yalnız “altyapı sunucusu” değil yüksek etkili ayrıcalıklı kontrol düzlemi olarak koruma gereğini destekler. S15

2026'da Belçika CCB, DragonForce'u bağlı kuruluş toplama ve “kartel” söylemiyle genişleyen bir RaaS operatörü olarak değerlendirdi. “Kartel” etiketi suç pazarlaması da olabilir; ortak altyapı, tek komuta veya kalıcı birleşme kanıtlanmadan örgütsel birlik varsayılmamalıdır. S36

Tarihin savunmaya bıraktığı yedi ders

1. Yedekleme gerekli ama tek başına yeterli değildir: Çift gasp, gizlilik ve düzenleyici baskıyı korur.
2. Marka kapatmak ekosistemi kapatmaz: Aktörler ve erişimler başka yapılara taşınabilir.
3. Kimlik yönetim düzlemidir: Yardım masası, SSO, bulut ve sanallaştırma hesapları kriz çarpanıdır.
4. Tedarikçi olayı sizin olayınızdır: Kritik dış hizmet için çıkış, görünürlük ve manuel süreç gerekir.
5. Yama önceliği internete açık ve aktif istismar edilen sistemlerde başlamalıdır: Yalnızca CVSS sırası iş riskini yakalamaz. S21
6. Şifreleme son işarettir: Erişim, ayrıcalık, keşif ve veri hareketi daha erken tespit fırsatları yaratır.
7. Kurtarma bir belge değil tatbikattır: Süre, veri kaybı, temiz ortam ve bağımlılıklar ölçülmeden plan doğrulanmış sayılmaz.

RaaS açısından neden önemli?

Tarih, RaaS'ın tek bir teknik buluştan değil; ödeme, erişim, uzmanlaşma ve gasp yöntemlerinin birleşiminden doğduğunu gösterir. Dönüm noktaları, savunmanın neden yalnızca zararlı yazılım imzasından kimlik, tedarik zinciri, veri ve kurtarma dayanıklılığına genişlemesi gerektiğini açıklar.

RaaS Ekonomisi

Yeraltı ekonomisi bir tedarik zinciridir

RaaS ekonomisi, birbirini her zaman tanımayan aktörlerin ürün ve hizmet alışverişi yaptığı bir suç tedarik zinciridir. “Grup” adı çoğu zaman şifreleyici markasını veya veri sızıntısı sitesini temsil eder; hedefe erişen, ağ içinde ilerleyen ve pazarlığı yürüten kişilerin tamamı aynı çekirdek örgütün üyesi olmayabilir. NCSC, olayın görünen ransomware adından daha nüanslı olduğunu ve çok sayıda kolaylaştırıcının rol oynadığını vurgular. S01

Gelir modelleri

RaaS programları tek bir fiyatlama modeline bağlı değildir:

• Gelir paylaşımı: Fidyenin belirli oranı operatöre, kalanı bağlı kuruluşa gider. 2025 tarihli DOJ kaydı, belirli ALPHV bağlı kuruluşlarının operatöre yüzde 20 pay vermeyi kabul ettiğini yargı belgesi üzerinden doğrular; bu oran tüm olaylar veya tüm RaaS programları için genellenemez. S60
• Abonelik veya lisans: Bağlı kuruluş araca süreli erişim için sabit ücret ödeyebilir.
• Tek seferlik satın alma: Şifreleyici ya da kaynak kod, platform hizmetleri olmadan satılabilir.
• Karma model: Giriş ücreti, performans komisyonu, depozito ve destek hizmetleri birlikte bulunabilir.
• Kapalı ortaklık: Kamuya açık affiliate ilanı yerine davetle çalışan küçük ekipler geliri paylaşabilir.

Bu modeller yeraltı pazarlarının kendi beyanlarına dayanabildiği için oranlar dikkatle okunmalıdır. Pazarlama mesajı, gerçekleşmiş ödeme veya gerçek örgütsel ilişkiyi kanıtlamaz.

Affiliate sistemi neden ölçek yaratır?

Bağlı kuruluş sistemi operatörün hedef bulma yükünü dağıtır. Farklı bağlı kuruluşlar farklı dil, sektör, ülke, erişim kanalı veya sosyal mühendislik becerisine sahip olabilir. Operatör merkezi yazılımı güncellerken bağlı kuruluşlar paralel kampanyalar yürütür. Başarılı programlar daha fazla bağlı kuruluş çeker; başarısız ödeme dağıtımı veya kolluk sızıntısı ise bağlı kuruluş göçünü hızlandırır.

Savunma açısından üç sonuç çıkar:

• Bir markanın geçmişte kullandığı tek erişim yöntemine aşırı odaklanmak risklidir.
• Bağlı kuruluş göçü nedeniyle farklı markalarda benzer davranış örüntüleri görülebilir.
• Marka adının değişmesi, kurumun kontrol önceliklerini kökten değiştirmemelidir; kritik kimlik, erişim ve veri yolları aynı kalır.

İlk erişim aracıları (Initial Access Brokers)

IAB, bir kuruma ait çalışır erişimi doğrudan gasp operasyonunu yürütmeden satan veya devreden aktördür. Erişim; internetten açık zayıf hizmet, geçerli hesap, kötüye kullanılan uzak erişim, ele geçirilmiş uç nokta veya tedarikçi bağlantısı gibi farklı kaynaklardan gelebilir. Burada önemli olan saldırı yöntemi değil, “erişimin bağımsız bir ticari mala dönüşmesi”dir. S01

IAB modelinin kuruma etkisi şöyledir: ilk ihlal ile ransomware etkisi arasında farklı aktörler ve zaman aralığı olabilir. Parola değişikliği tek başına yeterli olmayabilir; oturum belirteçleri, kalıcı erişim, cihaz kaydı, servis hesabı, e-posta kuralı ve üçüncü taraf yetkisi birlikte incelenmelidir. Eski veya kısa süreli bir alarm, haftalar sonra RaaS olayına dönüşebilecek erişimin ilk izi olabilir.

Kripto para kullanımı

Kripto varlıklar sınır ötesi, hızlı ve aracı kurumdan bağımsız ödeme olanağı sağladığı için ransomware ekonomisinde yaygındır. Fakat “tamamen anonim ve izlenemez” değildir. Kamuya açık blokzincirlerde işlem ilişkileri kalıcıdır; borsa kayıtları, cüzdan kümeleri ve adli el koyma süreçleri kolluk için kanıt üretebilir. Colonial Pipeline ödemesinin bir bölümü DOJ tarafından ele geçirildi. S41

Akademik ödeme çalışmaları, zincir üstü veriden ekonomik büyüklük çıkarmanın mümkün olduğunu fakat cüzdan atfı, zincir dışı ödeme, karıştırma ve eksik örneklem nedeniyle belirsizlik taşıdığını gösterir. S26 Bu nedenle “şu grup şu kadar kazandı” iddiaları yargı kaydı veya açık yöntem olmadıkça tahmin olarak etiketlenmelidir.

Kurum için doğru yaklaşım, ödeme mekanizmasını teknik ekip içinde doğaçlama tartışmak değildir. Hukuk, kolluk, düzenleyici yükümlülük, yaptırım riski, sigorta koşulları, delil koruma ve insan güvenliği birlikte değerlendirilmelidir. Ödeme yapılsa bile verinin silindiği, yayımlanmayacağı veya şifre çözmenin eksiksiz çalışacağı garanti edilmez.

Veri sızdırma siteleri

Veri sızdırma sitesi (DLS), saldırganın mağdur adını veya örnek veriyi yayımlayarak baskı kurduğu kanaldır. Ekonomik işlevi, şifreleme kozunu gizlilik ve itibar baskısıyla güçlendirmektir. Ancak DLS kayıtları aşağıdaki nedenlerle güvenilir mağdur veri tabanı değildir:

• Ödeme yapan kurumlar listeden çıkarılabilir; olay görünmez olur.
• Aynı olay birden çok marka tarafından sahiplenilebilir.
• Yayın tarihi, ilk erişim veya olay tarihi değildir.
• Kurum adı yanlış, eski veya yan kuruluş düzeyinde olabilir.
• Veri çalınmış olabilir ama şifreleme yapılmamış olabilir.
• Bazı kayıtlar pazarlama, korkutma veya bağlı kuruluş çekme amacı taşıyabilir.

Bu rehber DLS sayılarını “iddia edilen yayın” olarak ele alır. Gerçek vaka sayısı için kolluk şikâyeti, düzenleyici bildirim, olay müdahale kaydı ve mağdur açıklaması birlikte aranır. S10 S13

Hosting ve suç altyapısı

RaaS operasyonları; geçici sunucular, anonimleştirme katmanları, kötüye kullanılan meşru bulut hizmetleri, ele geçirilmiş sistemler ve dayanıklı barındırma sağlayıcılarının bir karışımını kullanabilir. Savunma için doğru hedef “belirli bir ülkeyi engellemek” değildir. IP ve alan adı hızla değişebilir; meşru hizmetler de kötüye kullanılabilir.

Etkili yaklaşım şunları birleştirir:

• Hangi uygulamanın hangi dış hedefle konuşmasının normal olduğunu bilmek.
• DNS, proxy, güvenlik duvarı, bulut denetim ve kimlik günlüklerini yeterli süre saklamak.
• Yeni, seyrek veya olağandışı veri çıkışını iş bağlamıyla incelemek.
• Güvenlik sağlayıcısı, barındırma şirketi, CERT ve kolluk için önceden temas noktası belirlemek.
• Yönetim konsollarını internete gereksiz biçimde açmamak ve ayrı yönetim ağı kullanmak.

İş bölümü ve ekosistem dayanıklılığı

Uzmanlaşma verimlilik sağlarken güven sorununu da büyütür. Operatör bağlı kuruluşun ödeme sakladığından, bağlı kuruluş operatörün anahtarı veya gelir payını teslim edeceğinden emin değildir. Kolluk operasyonları, forum sızıntıları ve iç anlaşmazlıklar markaları parçalayabilir. Buna rağmen ekosistem; erişim, kimlik, yazılım ve altyapının başka alıcılara aktarılmasıyla devam edebilir.

2024 LockBit bozma operasyonu ve ALPHV altyapı müdahalesi önemlidir; ancak NCSC 2025 değerlendirmesi tehdidin yüksek kaldığını ve ekosistemin çeşitlendiğini belirtir. S11 2025 BlackSuit/Royal operasyonunda sunucu ve alan adlarının ele geçirilmesi de kolluğun altyapı ve gelire aynı anda baskı uyguladığını gösterir. S58

RaaS ekonomisinin kurban dışındaki maliyeti

Fidye, toplam maliyetin yalnızca bir parçasıdır. İş kesintisi, manuel işlem, fazla mesai, dış olay müdahalesi, yeni altyapı, bildirim, çağrı merkezi, kredi izleme, hukuk, denetim, ceza riski, müşteri kaybı ve uzun süreli güven kaybı daha büyük olabilir. Change Healthcare 2024 mali bildiriminde doğrudan müdahale ve iş kesintisi etkilerini ayrı kalemler hâlinde bildirmiştir; sağlık ekosistemine sağlanan milyarlarca dolarlık faizsiz destek, üçüncü taraf nakit akışı etkisini ayrıca göstermiştir. S49 S50

Kritik hizmetlerde toplumsal maliyet daha ağırdır: geciken işlem, ertelenen ameliyat, yakıt veya gıda tedariki, vergi ve gümrük hizmetleri, bayi satış süreçleri ve laboratuvar sonuçları etkilenebilir. Bu dışsallıklar, RaaS riskinin yalnızca bilgi işlem bütçesiyle yönetilemeyeceğini gösterir.

Savunmacı için ekonomik karşı hamle

Amaç saldırganı “hacklemek” değil, iş modelinin beklenen getirisini düşürmektir:

• Erişim maliyetini phishing-resistant MFA, güvenli yapılandırma ve hızlı yama ile yükseltmek.
• Ağ içi ilerleme ve ayrıcalık kazanma süresini segmentasyon, PAM ve sürekli izlemeyle uzatmak.
• Veri sızıntısı değerini sınıflandırma, minimum veri tutma, şifreleme ve çıkış görünürlüğüyle azaltmak.
• Şifreleme baskısını değiştirilemez/çevrimdışı yedek ve test edilmiş kurtarmayla düşürmek.
• Kriz kararlarını tatbikat, iletişim planı ve hukuki ön hazırlıkla hızlandırmak.
• Olayı bildirmek ve göstergeleri paylaşmak suretiyle kolluk ve sektör savunmasını güçlendirmek.

RaaS açısından neden önemli?

RaaS'ın gücü yalnızca şifreleyicide değil, erişimden ödemeye uzanan ekonomik iş bölümündedir. Bu bölüm rolleri ve gelir mantığını açıklayarak savunmanın neden tek ürüne değil, suç zincirinin her aşamasındaki maliyet ve başarısızlık noktalarına yerleştirilmesi gerektiğini gösterir.

Bir RaaS Operasyonu Nasıl İşler?

Kavramsal akış ve güvenli anlatım sınırı

Bu bölüm bir saldırı reçetesi değildir. Adımlar her olayda aynı sırayla görülmez; bazıları atlanır, eş zamanlı yürür veya başka aktöre devredilir. “İlk erişim” bir IAB'den satın alınmış olabilir; “veri sızdırma” şifrelemeden günler önce tamamlanabilir; bazı modern gasp olaylarında şifreleme hiç yapılmayabilir. Amaç, savunmacının zincirde erken müdahale edebileceği yerleri görünür kılmaktır. S01 S13

1. Hedef seçimi

Amaç

Hedef seçimi, saldırganın erişim olasılığı ile ödeme veya baskı potansiyelini karşılaştırdığı aşamadır. RaaS bağlı kuruluşları her zaman belirli sektöre ideolojik olarak yönelmez. NCSC, çoğu siber suçlunun sektör bağımsız hareket ettiğini; ödeme ihtimali, kesintiye hassasiyet ve sızdırıldığında ağır zarar doğuracak veri gibi ölçütlere baktığını belirtir. S11

Saldırgan ne yapmaya çalışıyor?

Saldırgan; internete açık hizmetler, kamuya açık teknoloji bilgileri, çalışan/tedarikçi ilişkileri, geçmiş sızıntılar ve erişim pazarları üzerinden “kolay erişim + yüksek baskı” birleşimini arar. Kurumun gelir dönemleri, kritik operasyon saatleri veya yasal bildirim hassasiyeti baskıyı artırabilir. Bu analiz çoğu zaman kusursuz değildir; geniş ve fırsatçı tarama da hedefe dönüşebilir.

Kurum bunu nasıl fark edebilir?

• İnternete açık varlıklarda olağandışı tarama, kimlik doğrulama denemesi veya keşif yoğunluğu.
• İşe alım, tedarikçi ve çalışan bilgilerine yönelik şüpheli temaslar.
• Kuruma ait kimlik bilgilerinin güvenilir tehdit istihbaratı kaynaklarında görünmesi.
• Unutulmuş alt alan adı, eski VPN, test sistemi veya üçüncü taraf portalı gibi sahipsiz varlıklar.
• Yardım masasına kullanıcı adına SIM/MFA sıfırlama veya hesap kurtarma baskısı.

Bu işaretlerin hiçbiri tek başına RaaS kanıtı değildir. Değerleri, kurumun varlık ve kimlik envanteriyle ilişkilendirildiğinde ortaya çıkar.

Nasıl engellenebilir veya etkisi azaltılabilir?

• Dış saldırı yüzeyi envanterini sürekli güncelleyin; her varlığa iş sahibi ve kapatma tarihi atayın.
• İnternete açık yönetim arabirimlerini kaldırın veya güçlü, cihaz bağlı erişimle sınırlandırın.
• İş ilanı ve teknik dokümanlarda gereksiz mimari/ürün ayrıntısını azaltın; güvenlik iletişimlerini gizlemeyin ama operasyonel ayrıntıyı sınırlayın.
• Kritik hizmet, gelir, hasta/üretim/lojistik bağımlılığı ve veri hassasiyetini iş etki analizinde haritalayın.
• Tehdit istihbaratını otomatik blok listesinden çok, önceliklendirme ve hipotez üretme aracı olarak kullanın.

2. İlk erişim

Amaç

İlk erişim, saldırganın kurum içindeki bir hesap, cihaz, uygulama veya tedarikçi bağlantısını kullanabilir hâle gelmesidir. RaaS ekosisteminde bu erişim doğrudan bağlı kuruluş tarafından sağlanabileceği gibi bir IAB'den satın alınabilir. S01

Saldırgan ne yapmaya çalışıyor?

Genel kategoriler; ele geçirilmiş veya yeniden kullanılmış kimlik bilgisi, insan manipülasyonu, aktif istismar edilen internet hizmeti, güvensiz uzak erişim ve üçüncü taraf güven ilişkileridir. Bu rehber yöntemlerin uygulanışını öğretmez. Savunma açısından önemli nokta, erişimin çoğu zaman “geçerli görünen” kimlik veya meşru yönetim aracı üzerinden gelebilmesidir.

Kurum bunu nasıl fark edebilir?

• Kullanıcının normal cihazı, coğrafyası, saati veya eriştiği kaynaklarla uyuşmayan oturumlar.
• MFA yönteminde beklenmeyen ekleme, sıfırlama veya ardışık bildirim baskısı.
• Eski hesap, servis hesabı veya tedarikçi hesabında yeni etkileşim.
• İnternete açık uygulamada bilinen istismar sonrası olağandışı işlem veya çocuk süreç davranışı.
• Yeni uzak yönetim aracı, yetkisiz cihaz kaydı veya güvenlik ilkesi değişikliği.
• Aynı kimliğin kısa sürede birbirinden uyumsuz ağlardan oturum açması; oturum belirteci kötüye kullanımına işaret eden cihaz/oturum tutarsızlığı.

Nasıl engellenebilir veya etkisi azaltılabilir?

• E-posta, VPN, bulut, yönetim ve kritik uygulamalarda phishing-resistant MFA'yı önceliklendirin. SMS/tek kullanımlık kod, MFA'sızlıktan iyidir fakat kimlik avına dayanıklı değildir. S17
• İnternete açık sistemleri CISA KEV ve iş kritikliğine göre yamalayın; yalnızca genel önem puanına göre sıralamayın. S21
• Eski protokol ve MFA'yı atlayan kimlik doğrulama yollarını kapatın.
• Tedarikçi erişimini süreli, onaylı, cihaz bağlı ve kayda alınmış hâle getirin.
• Yardım masasında kimlik doğrulama ve MFA sıfırlama için sözlü bilgiye dayanmayan güçlü prosedür uygulayın.
• Şüpheli erişimde yalnızca parola değiştirmeyin; aktif oturumları, belirteçleri, cihaz kayıtlarını, erişim anahtarlarını ve e-posta/SSO kurallarını da iptal edin.

3. Yetki artırma

Amaç

Yetki artırma, sınırlı kullanıcı erişimini daha geniş sistem, veri veya güvenlik yönetimi yetkisine dönüştürmektir. RaaS etkisinin büyüklüğü çoğu zaman şifreleyicinin gücünden çok, saldırganın dizin, sanallaştırma, yedek, bulut ve güvenlik konsoluna ulaşabilmesinden kaynaklanır.

Saldırgan ne yapmaya çalışıyor?

Saldırgan zayıf rol ayrımı, fazla yetkili hesap, yanlış yapılandırma, güncel olmayan ayrıcalıklı yazılım, ele geçirilmiş yönetici oturumu veya korumasız servis kimliği gibi fırsatlardan yararlanarak daha geniş kontrol arar. Amaç; güvenlik araçlarını etkisizleştirmek, yedekleri silmek/değiştirmek, kritik verilere erişmek veya yayılmayı hızlandırmaktır.

Kurum bunu nasıl fark edebilir?

• Kullanıcının görev tanımıyla uyuşmayan rol/grup üyeliği değişikliği.
• Yeni yönetici hesabı, erişim anahtarı, uygulama kaydı veya bulut rolü.
• Ayrıcalıklı oturumun onay süreci dışında başlatılması.
• EDR, günlükleme, yedekleme veya kimlik ilkesinde beklenmeyen değişiklik.
• Kimlik kasasından olağandışı sır çekme veya kısa sürede çok sayıda ayrıcalıklı sisteme erişim.
• Servis hesabının ilk kez etkileşimli oturum açması.

Nasıl engellenebilir veya etkisi azaltılabilir?

• Günlük kullanıcı hesabı ile ayrıcalıklı yönetim hesabını ayırın.
• Kalıcı yönetici yerine tam zamanında ve süreli yetki verin; gerekçe/onay kaydı tutun.
• Ayrıcalıklı erişim iş istasyonları veya yönetim ağı kullanın.
• Servis hesaplarını en az yetkiyle, döndürülen sırlarla ve etkileşimli oturuma kapalı çalıştırın.
• Kritik rol değişiklikleri ve güvenlik kontrolü kapatma işlemleri için bağımsız alarm üretin.
• PAM'in kendisini yüksek değerli yönetim düzlemi olarak yedekleyin, izleyin ve ayrı güven sınırına alın.

4. Ağ içinde yayılma

Amaç

Ağ içinde yayılma, ilk ele geçirilen noktadan kritik sunuculara, kullanıcı gruplarına ve yönetim sistemlerine ulaşma çabasıdır. RaaS etkisini “bir dizüstü bilgisayardan kurum çapında kesintiye” taşıyan temel aşamalardan biridir.

Saldırgan ne yapmaya çalışıyor?

Saldırgan güven ilişkilerini, ortak yönetim kanallarını, paylaşılan kimlikleri ve düz ağ yapısını kullanarak erişim alanını büyütmeye çalışır. Meşru yönetim protokolleri ve araçları kötüye kullanılabildiğinden, yalnızca “zararlı dosya var mı?” sorusu yeterli değildir.

Kurum bunu nasıl fark edebilir?

• Bir kullanıcı veya cihazdan kısa sürede çok sayıda sunucuya kimlik doğrulama.
• İş rolüyle uyuşmayan yönetim paylaşımı, uzak yönetim veya dizin sorgusu.
• İlk kez görülen cihazdan yönetici oturumu.
• Kullanıcı segmentinden yedek, hipervizör veya etki alanı yönetim arabirimine erişim.
• Aynı hesabın çok sayıda başarısız denemenin ardından birden fazla hedefte başarı elde etmesi.
• Normal bakım penceresi dışında toplu uzaktan işlem veya politika değişikliği.

Nasıl engellenebilir veya etkisi azaltılabilir?

• Kullanıcı, sunucu, üretim, yedek, yönetim, sanallaştırma ve güvenlik ağlarını iş ihtiyacına göre ayırın.
• Varsayılan olarak doğu-batı trafiğini serbest bırakmayın; gerekli akışları belgeleyip izin verin.
• Yönetim protokollerini yalnızca ayrı yönetim noktalarından kabul edin.
• Yerel yönetici parolalarını benzersiz ve otomatik döndürülen hâle getirin.
• Mikrosegmentasyonu tek seferlik büyük dönüşüm yerine kritik hizmetten başlayarak aşamalı uygulayın. S19
• Segmentasyon kuralını yedekleyin ve acil durumda güvenli biçimde geri alabilecek değişiklik yönetimi kurun.

5. Veri toplama

Amaç

Veri toplama, gasp değeri taşıyan bilgiyi bulma, bir araya getirme ve dışarı çıkarılmaya hazırlama aşamasıdır. Şifreleme yapılmasa bile veri toplama ve sızdırma tek başına RaaS bağlantılı gasp olayına dönüşebilir. Cl0p/MOVEit kampanyası bunun önemli örneklerindendir. S31

Saldırgan ne yapmaya çalışıyor?

Saldırgan kişisel veri, sağlık kaydı, sözleşme, kimlik belgesi, fikrî mülkiyet, finansal bilgi, yedek veya iç iletişim gibi baskı değerini artıracak içeriği arar. Dosyaları geçici bir konumda toplamak, sıkıştırmak veya toplu erişime hazırlamak olası davranış kategorileridir; burada araç/komut ayrıntısı verilmez.

Kurum bunu nasıl fark edebilir?

• Tek hesabın kısa sürede normalden çok daha fazla hassas klasör veya kayda erişmesi.
• Yeni oluşturulan büyük arşivler veya geçici depolama alanında olağandışı büyüme.
• Kullanıcının sorumluluğu dışındaki veri sınıflarını araması ya da toplu sorgulaması.
• Yedek depoları, belge yönetimi, e-posta arşivi veya veri ambarında anormal okuma.
• Hizmet hesabının alışılmadık veri türlerine erişmesi.
• Bulut depolama üzerinde toplu indirme, dışa aktarma veya paylaşım ilkesi değişikliği.

Nasıl engellenebilir veya etkisi azaltılabilir?

• Hassas verinin nerede olduğunu, sahibini, saklama süresini ve iş gerekçesini kaydedin.
• Gereksiz veriyi tutmayın; “çalınabilecek veri yoksa” gasp yüzeyi de küçülür.
• Depo ve uygulama düzeyinde en az yetki uygulayın; ağ erişimi veri erişimi anlamına gelmesin.
• Toplu okuma ve dışa aktarmayı ayrı alarm/işlem onayına bağlayın.
• Veri sınıflandırma etiketlerini DLP, bulut erişim politikası ve olay önceliğiyle ilişkilendirin.
• Üretim verisini test/geliştirme ortamlarına kontrolsüz kopyalamayın.

6. Veri sızdırma

Amaç

Veri sızdırma, çalınan bilgiyi kurumun kontrol alanı dışına çıkararak yayın veya satış tehdidi kurmaktır. Modern olaylarda veri hırsızlığı sık görülür; ancak tek bir olay müdahale sağlayıcısının oranı bütün dünyaya genellenmemelidir. S13

Saldırgan ne yapmaya çalışıyor?

Saldırgan meşru bulut depolama, şifreli iletişim, geçici altyapı veya ele geçirilmiş sistemleri kötüye kullanarak veri çıkarmaya çalışabilir. Hedef, ağ trafiğini “normal hizmet kullanımı” gibi göstermek ve DLP/çıkış kontrollerinden kaçınmaktır.

Kurum bunu nasıl fark edebilir?

• Daha önce görülmeyen dış hizmete uzun süreli veya yüksek hacimli veri çıkışı.
• Kullanıcı/uygulamanın normal taban çizgisine göre ani yükleme artışı.
• Hassas veri kaynağından yeni dış paylaşım veya herkese açık bağlantı.
• DNS, proxy ve bulut günlüklerinde tek olayla açıklanamayan ardışık nadir hedefler.
• Büyük arşiv oluşturma ile dış veri aktarımının zaman bakımından ilişkili olması.
• Mesai dışı toplu dışa aktarma ve hemen ardından oturum/iz silme davranışı.

Nasıl engellenebilir veya etkisi azaltılabilir?

• Çıkış trafiğini uygulama ve kimlik bağlamıyla izleyin; yalnızca IP/port listesine güvenmeyin.
• Kurumsal onaylı depolama ve dosya aktarım kanallarını belirleyin; diğerlerini risk temelli sınırlandırın.
• Hassas veri için dış paylaşım, toplu indirme ve yüksek hacimli API kullanımına ek doğrulama/onay uygulayın.
• DLP'yi ilk günden “her şeyi engelle” biçiminde değil, görünürlük → uyarı → seçici engelleme aşamalarıyla devreye alın.
• Uç nokta, ağ ve bulut telemetrisini ortak zaman çizelgesinde korele edin.
• Veri sızıntısı ihtimalini olay planında şifrelemeden bağımsız bildirim ve iletişim senaryosu olarak ele alın.

7. Şifreleme ve hizmeti bozma

Amaç

Şifreleme, veriyi erişilemez kılarak iş kesintisi ve zaman baskısı oluşturur. Modern RaaS operasyonları ayrıca yedek silme, kurtarma ayarı değiştirme, sanallaştırma yönetimini ele geçirme veya güvenlik araçlarını kapatma yoluyla toparlanmayı zorlaştırmaya çalışabilir. Bu nedenle “uç noktada dosya şifreleme” son etkinin yalnızca bir biçimidir. S13 S14

Saldırgan ne yapmaya çalışıyor?

Saldırgan mümkün olan en geniş hizmet alanını eş zamanlı etkileyip kurtarma seçeneklerini azaltmak ister. Merkezi yönetim sistemleri bu nedenle yüksek değerli hedeftir: bir hipervizör, yedek konsolu veya etki alanı yetkisi çok sayıda iş yüküne ulaşabilir.

Kurum bunu nasıl fark edebilir?

• Çok sayıda dosyada kısa sürede ad/uzantı/değişim davranışı.
• Yedek silme, saklama politikasını kısaltma veya anlık görüntü değişikliği.
• Hipervizör, bulut ya da depolama yönetiminde toplu güç/disk/erişim işlemi.
• Güvenlik ajanının kapatılması, korunmuş ayar değişikliği veya günlük kaynağının susması.
• Dosya sunucularında olağandışı yeniden adlandırma, yüksek yazma ve erişim hatası oranı.
• Birden çok sistemde aynı zaman aralığında hizmet durması veya yeniden başlatma.

Nasıl engellenebilir veya etkisi azaltılabilir?

• Yedek yönetim kimliğini üretim dizininden ayırın; yedek silme için güçlü MFA ve ikinci onay kullanın.
• Değiştirilemez saklama, çevrimdışı kopya ve ayrı hesap/abonelik sınırı uygulayın. S08
• EDR'nin kurcalamaya karşı korumasını açın ve kapatma olayını bağımsız kanala iletin.
• Kritik dosya/paylaşım davranışında otomatik izolasyon kararını önce dar kapsamlı test edin; yanlış pozitifin klinik veya üretim etkisini değerlendirin.
• Hipervizör, RMM, yedek ve bulut yönetim düzlemini ayrıcalıklı Tier-0 benzeri sınıfta koruyun.
• Geri yüklemeyi yalnızca dosya düzeyinde değil, kimlik, DNS, uygulama, veri tabanı ve dış bağımlılıklarla uçtan uca test edin.

8. Fidye talebi

Amaç

Fidye talebi, teknik etkiyi süreli ve psikolojik baskıya dönüştürür. Not; şifre çözme, veri silme veya yayımlamama karşılığında ödeme ister. Bazı olaylarda saldırgan müşterilere veya çalışanlara ulaşarak baskıyı artırmaya çalışır.

Saldırgan ne yapmaya çalışıyor?

Saldırgan kurumda yetki karmaşası, kamuoyu korkusu ve hizmet kesintisi süresini kullanır. Talebin “son tarih” veya “indirim” dili, teknik gerçeği değil pazarlık taktiğini yansıtır. Şifre çözme örneği göstermek, tüm sistemlerin geri döneceği veya verinin silineceği garantisi değildir.

Kurum bunu nasıl fark edebilir?

Fidye notu zaten geç işarettir. Daha değerli olan, önceki aşamaların kimlik, rol değişikliği, veri hareketi, yedek müdahalesi ve güvenlik aracı kurcalama sinyalleridir. Talep geldiğinde kurum şunları doğrulamalıdır:

• Talebin hangi sistemde ve ne zaman görüldüğü.
• Verinin şifrelenip şifrelenmediği, dışarı çıkarıldığına dair bağımsız kanıt olup olmadığı.
• Hangi hizmet ve kimlik alanının etkilendiği.
• Saldırganla temas kurulup kurulmadığı ve kim tarafından kurulduğu.
• İnsan güvenliği veya kritik hizmet açısından acil risk bulunup bulunmadığı.

Nasıl engellenebilir veya etkisi azaltılabilir?

• Fidye notunu silmeden ve saldırganla doğaçlama temas kurmadan olay ekibini etkinleştirin.
• Görüntü, zaman, dosya yolu ve ilişkili günlükleri delil bütünlüğüyle koruyun.
• Tek sözcü, tek karar günlüğü ve hukuk onaylı iletişim kanalı belirleyin.
• Kolluk/CERT, düzenleyici, sigorta ve dış olay müdahale sözleşmelerini önceden hazırlayın.
• Ödeme kararını teknik ekibe bırakmayın; hukuk, yaptırım riski, insan güvenliği, operasyon, delil ve yönetim kurulu yetkisi birlikte değerlendirilmelidir.

9. Pazarlık

Amaç

Pazarlık, saldırganın ödeme alma olasılığını artırmaya çalıştığı iletişim evresidir. Bu rehber pazarlık senaryosu, ödeme düşürme taktiği veya saldırganla iletişim talimatı vermez. Konu; yönetişim, kanıt ve risk sınırıyla ele alınır.

Saldırgan ne yapmaya çalışıyor?

Saldırgan kesinti ve veri baskısını kullanır, kurumun ödeme kapasitesini tahmin eder, zaman baskısı kurar veya küçük veri örnekleriyle iddiasını desteklemeye çalışır. Suçlunun beyanı doğrulanmış adli kapsam değildir. “Veriyi sileceğiz”, “başka yerde kopya yok” veya “bir daha saldırmayacağız” gibi sözler teknik olarak denetlenebilir garanti sunmaz.

Kurum bunu nasıl fark edebilir?

Pazarlık aşamasında tespit sorusu, saldırıyı fark etmekten çok temas bütünlüğünü korumaktır:

• Kurum içinde saldırganla kimlerin temas kurduğunu kaydedin.
• Sahte aracı, taklit hesap veya ikinci gasp girişimi ihtimalini değerlendirin.
• Her iddiayı adli inceleme ve veri envanteriyle ayrı doğrulayın.
• Çalışanlara, medyaya veya müşteriye giden tehdit mesajlarını olay kaydına alın.
• Ödeme veya iletişimle ilgili hiçbir kişisel cihaz/hesap kullanılmamasını sağlayın.

Nasıl engellenebilir veya etkisi azaltılabilir?

• Yetkili dış uzman ve hukuk danışmanını önceden sözleşmeyle hazırlayın; kriz anında tedarikçi seçmeye çalışmayın.
• Yönetim kurulunun karar yetkisi ve karar için gereken kanıt setini önceden belirleyin.
• Kolluk ve yaptırım taraması yapılmadan mali taahhütte bulunmayın.
• Pazarlığı kurtarmanın yerine koymayın; temiz ortam, kritik hizmet önceliği ve bildirim süreçleri paralel yürüsün.
• Suçlunun veri silme beyanına güvenerek mağdur bildirimini veya izlemeyi durdurmayın.

10. Sonuç ve saldırı sonrası olasılıklar

Amaç

Saldırgan açısından sonuç; ödeme, veri yayımlama, yeniden satış, marka itibarı veya başka bir hedefe geçiş olabilir. Kurum açısından teknik sistemlerin açılması olayın bittiği anlamına gelmez. Kimlik güveni, veri ihlali kapsamı, üçüncü taraf etkisi, hukuki yükümlülük ve yeniden saldırı riski devam eder.

Saldırgan ne yapmaya çalışıyor?

Ödeme yapılsa da yapılmasa da saldırgan erişimi yeniden satabilir, çalınan veriyi saklayabilir, aynı erişimle tekrar deneyebilir veya başka marka adına olay yürütülebilir. Bu nedenle yalnızca şifreli dosyaları açmak, kök nedeni ve erişim kalıntılarını ortadan kaldırmaz.

Kurum bunu nasıl fark edebilir?

• Kurtarma sonrasında eski belirteç, servis hesabı veya cihaz kaydıyla yeniden erişim denemesi.
• Aynı veri setinin başka suç kanallarında ortaya çıkması.
• Temizlendiği varsayılan sistemden tekrarlayan anormal iletişim.
• Yeni marka/aktör adına ikinci gasp mesajı.
• Yedekten dönen eski zafiyet veya yanlış yapılandırmanın tekrar etkinleşmesi.

Nasıl engellenebilir veya etkisi azaltılabilir?

• “Temiz geri yükleme” ölçütü tanımlayın: güvenilir imaj, yamalı sistem, döndürülmüş sır, iptal edilmiş oturum ve doğrulanmış günlükleme.
• Etki alanı/bulut kimliği, sertifika, API anahtarı, servis hesabı ve tedarikçi erişimini risk sırasıyla yenileyin.
• Kök neden doğrulanmadan tüm ağı aynı anda açmayın; kritik hizmetleri kontrollü dalgalarla devreye alın.
• En az birkaç hafta yoğun izleme ve tehdit avcılığı sürdürün.
• Olay derslerini sahip, bütçe ve son tarihle düzeltici faaliyete dönüştürün; yalnızca “farkındalık artırılacak” gibi ölçülemez sonuç bırakmayın.
• Yönetim kuruluna teknik gösterge yerine hizmet, veri, hukuk, maliyet ve kalan risk görünümü sunun.

Savunma açısından en değerli kırılma noktaları

RaaS açısından neden önemli?

RaaS operasyonu tek bir “şifreleme anı” değildir; bağımsız suç hizmetlerinin birbirine eklenebildiği bir süreçtir. Bu bölüm her aşamayı saldırganın amacı, savunmacının görebileceği işaret ve önleyici kontrolle eşleştirerek kuruma şifrelemeden önce çok sayıda müdahale fırsatı bulunduğunu gösterir.

RaaS Grupları ve Markaları

Grup adlarını doğru okumak

Bir RaaS adı; yazılım ailesi, hizmet markası, veri sızıntısı sitesi, operatör çekirdeği veya bağlı kuruluşların gevşek birleşimi olabilir. Aynı aktör birden çok markada çalışabilir; aynı marka farklı bağlı kuruluşların birbirinden farklı yöntemlerini barındırabilir. Bu nedenle aşağıdaki profiller “tek ve değişmez örgüt şeması” değildir. Amaç, tarihsel etkiyi ve savunma dersini karşılaştırmaktır. S01

Atıf uyarısı: Bir failin olayı sızıntı sitesinde sahiplenmesi doğrulama değildir. “Büyük saldırıları” alanında resmî atıf, mağdur bildirimi veya güvenilir kamu değerlendirmesi yoksa bu durum açıkça yazılmıştır.

22 Temmuz 2026 durum özeti

LockBit

Ortaya çıkışı

LockBit 2019 civarında görünür hâle geldi ve zaman içinde 2.0/Red, 3.0/Black gibi sürüm adlarıyla RaaS programını yeniledi. CISA ve ortakları, LockBit'i geniş sektör ve ülke kapsamına ulaşmış, bağlı kuruluş tabanlı bir tehdit olarak belgeledi. S27

Faaliyet yılları

2019–2026. Şubat 2024'te uluslararası Operation Cronos kapsamında altyapı ele geçirildi ve yöneticiler hakkında adımlar atıldı. Buna rağmen NCSC 2025, LockBit bozulmasının ardından ransomware tehdidinin yüksek ve ekosistemin çeşitlenmiş kaldığını vurguladı. 2025–2026 kaynakları markanın geri dönüş girişimlerini gösterir; “eski ölçekte ve tek merkezli” olduğu varsayılmamalıdır. S11 S28

Hedef sektörler

Kamu, imalat, finans, profesyonel hizmet, sağlık ve kritik altyapı dâhil geniş bir yelpaze. Bu genişlik, tek sektöre özel ideolojik hedeflemeden çok fırsat ve ödeme baskısı seçimine işaret eder.

Bilinen özellikleri

• Geniş bağlı kuruluş ağı ve program sürümleri.
• Veri sızıntısı ile şifrelemeyi birleştiren çift gasp modeli.
• Bağlı kuruluşlara göre değişen ilk erişim ve operasyon davranışları.
• Marka görünürlüğünü bağlı kuruluş çekmek için kullanan suç pazarlaması.

Büyük saldırıları ve ölçek

CISA'nın 2023 ortak uyarısı, LockBit'in 2022'de dünya çapında en çok konuşlandırılan ransomware varyantı olduğunu ve ABD'de 2020 başından 2023'ün ilk çeyreğine kadar yaklaşık 1.700 saldırı ile yaklaşık 91 milyon ABD doları fidye ödemesiyle ilişkilendirildiğini bildirdi. Bu rakamlar yalnızca bilinen/raporlanan kapsama aittir. S27

Durumu

Aktif fakat bozulmuş ve parçalı. “LockBit” etiketi 2024 öncesindeki örgütsel bütünlüğün sürdüğünü kanıtlamaz. Savunma ekipleri marka IOC'lerini izlerken geçerli hesap, yönetim düzlemi, veri çıkışı ve yedek müdahalesi davranışlarını esas almalıdır.

Savunma dersi

Bir bozma operasyonundan sonra alarm kurallarını kapatmayın. Eski bağlı kuruluşların yeni adlarla aynı erişim yollarını kullanabileceği varsayımıyla kimlik ve ağ davranışlarını izlemeye devam edin.

Conti

Ortaya çıkışı

Conti 2020'de yüksek tempolu operasyonlarıyla görünür oldu ve gelir paylaşımı, işe alım ve operasyon katmanlarıyla RaaS/özel ortaklık sınırında büyük bir suç yapısı olarak değerlendirildi. CISA, FBI, NSA ve U.S. Secret Service 2021'de Conti faaliyetlerine karşı ortak danışma belgesi yayımladı. S29

Faaliyet yılları

Ana marka yaklaşık 2020–2022 arasında faaldi. 2022'de iç yazışma sızıntıları, politik açıklamalar ve kolluk baskısı sonrasında marka kapandı. Ancak eski üyelerin, bağlı kuruluşların ve yöntemlerin başka gruplarda sürmesi “Conti sonrası diaspora” kavramını doğurdu.

Hedef sektörler

Sağlık, kamu, eğitim, acil hizmet, imalat ve profesyonel hizmetler dâhil kesintiye duyarlı kuruluşlar.

Bilinen özellikleri

• Yapılandırılmış iş bölümü ve yüksek operasyon temposu.
• Veri hırsızlığı ile şifrelemeyi birleştiren gasp.
• Bağlı kuruluşlar ve başka suç araçlarıyla ekosistem ilişkisi.
• Marka kapanışı sonrasında personel ve erişim ağının dağılması.

Büyük saldırıları

Costa Rica kamu kurumlarına 2022'de yapılan saldırılar Conti ile resmî olarak ilişkilendirildi; vergi, gümrük ve diğer kamu hizmetlerinde uzun süreli kesinti oluştu. Dünya Bankası değerlendirmesi etkiyi yaklaşık 26 kurum, 56 gün ve GSYH'nin yaklaşık yüzde 2,4'üne ulaşan tahmini zarar bağlamında ele alır. Bu GSYH oranı doğrudan muhasebe kaybı değil, modelleme/tahmindir. S56 S57

Durumu

Marka kapalı; mirası sürüyor. “Conti saldırısı” ifadesi 2022 sonrasındaki her benzer olay için kullanılmamalıdır. Aktör sürekliliği ancak yargı, altyapı veya güçlü teknik kanıtla kurulabilir.

Savunma dersi

Tehdit modelini marka listesine bağlamayın. Erişim aracısı, kimlik istismarı, ayrıcalık ve veri çıkışı gibi taşınabilir yetenekleri kontrol edin.

REvil (Sodinokibi)

Ortaya çıkışı

REvil/Sodinokibi 2019'da görünür olan, yüksek profilli hedefler ve bağlı kuruluş modeliyle tanınan bir RaaS programıdır. Yargı kayıtları, iştiraklerin operatör altyapısını kullanarak saldırı yürüttüğünü ve gelir paylaştığını doğrulamıştır. S37

Faaliyet yılları

Ana operasyon yaklaşık 2019–2021 döneminde en görünür hâlindeydi. 2021 sonu ve 2022'de altyapı bozma, tutuklama ve operasyonel çöküş yaşandı. Bağlı kuruluşlara ilişkin yargı süreçleri daha sonra da sürdü.

Hedef sektörler

Gıda, teknoloji yönetim hizmetleri, profesyonel hizmetler, imalat ve çok sayıda alt müşterisi olan yazılım/servis sağlayıcıları.

Bilinen özellikleri

• RaaS operatörü ile sahadaki bağlı kuruluş arasında rol ayrımı.
• Yüksek profilli hedefler ve veri yayımlama baskısı.
• MSP/tedarik zinciri etkisi yaratabilecek yazılım ve yönetim altyapılarına yönelim.

Büyük saldırıları

FBI, 2021 JBS olayını REvil/Sodinokibi'ye atfetti; JBS kendi açıklamasında 11 milyon ABD doları ödeme yaptığını bildirdi. S42 S43 Temmuz 2021 Kaseya VSA olayı da REvil ile ilişkilendirildi; Kaseya yaklaşık 50 doğrudan müşterinin etkilendiğini bildirdi, aşağı akıştaki müşteri sayısına ilişkin daha büyük rakamlar ise farklı tanım ve haber tahminlerine dayanır. S44 S45

Durumu

Ana hizmet etkisiz/inaktif kabul ediliyor; yargı takibi sürüyor. REvil kodu, yöntemi veya eski bağlı kuruluşların başka markalarda görülmesi ana programın yeniden faal olduğu anlamına gelmez.

Savunma dersi

RMM, MSP ve merkezi yazılım dağıtım sistemini sıradan uygulama değil, yüksek etkili yönetim düzlemi olarak sınıflandırın; imzalı güncelleme bile olağandışı dağıtım davranışı gösteriyorsa doğrulayın.

BlackCat (ALPHV)

Ortaya çıkışı

ALPHV/BlackCat 2021 sonlarında görünür oldu ve teknik açıdan farklı platformları hedefleyebilen RaaS hizmetiyle tanındı. Kamu değerlendirmeleri, DarkSide/BlackMatter ekosisteminden deneyimli aktörlerle olası süreklilik kurdu; bu tür soy ilişkileri kesin üyelik listesi değildir.

Faaliyet yılları

Yaklaşık 2021–Mart 2024. FBI Aralık 2023'te altyapıya yönelik bozma eylemi yürüttü. Şubat 2024'te sağlık sektörüne yönelik faaliyetler için güncel uyarı yayımlandı. Change Healthcare ödemesi sonrasında 2024 Mart'ında operatörün bağlı kuruluşa pay vermeden kapandığı/çıkış yaptığına ilişkin güçlü kamu değerlendirmeleri oluştu. S30

Hedef sektörler

Sağlık, konaklama, finans, enerji, teknoloji ve kritik altyapı dâhil geniş sektörler.

Bilinen özellikleri

• Bağlı kuruluşlara platform ve gasp altyapısı sağlama.
• Windows ve Linux/sanallaştırma ortamlarına uzanan çoklu platform yaklaşımı.
• Çift gasp ve yüksek görünürlüklü hedefler.
• Operatör-bağlı kuruluş güven ilişkisinin kırılganlığı.

Büyük saldırıları

Change Healthcare olayı ALPHV/BlackCat bağlı kuruluşuyla ilişkilendirildi; Kongre yanıtları, MFA bulunmayan eski bir Citrix portalından ele geçirilmiş kimlik bilgisiyle erişim sağlandığını açıklar. S48 S50 MGM 2023 olayı güçlü kamu atfıyla ALPHV ve Scattered Spider ekosistemiyle ilişkilendirildi; ancak MGM'nin SEC bildirimi aktörü adlandırmaz. MGM yaklaşık 100 milyon ABD doları olumsuz düzeltilmiş EBITDAR etkisi bildirdi. S46 S61

Durumu

Marka inaktif/çökmüş; bağlı kuruluşlar dağılmıştır. 2025 tarihli DOJ suç kabulü, 2023'te bağlı kuruluşların operatöre yüzde 20 gelir payı verdiğini yargı kaydıyla gösterir; bu, markanın 2025'te aktif olduğu anlamına gelmez. S60

Savunma dersi

“Eski” uygulamayı MFA kapsamı dışında bırakmayın. SSO, Citrix/VPN ve destek süreçlerindeki istisnalar, en güçlü modern kimlik kontrolünü etkisiz hâle getirebilir.

Cl0p (Clop)

Ortaya çıkışı

Cl0p 2019 civarında görünür oldu; zaman içinde klasik şifreleme operasyonlarından, geniş kitleli dosya aktarım uygulaması açıklarını hedefleyen veri hırsızlığı ve gasp kampanyalarına evrildi.

Faaliyet yılları

2019–2026 döneminde marka/faaliyet izleri sürmektedir. Kesim tarihinde aktif kabul edilir; ancak her Cl0p iddiası bağımsız doğrulanmış değildir.

Hedef sektörler

Dosya aktarım ürünlerini kullanan kamu, finans, eğitim, sağlık, profesyonel hizmet ve tedarik zinciri kuruluşları. Asıl ortak nokta sektör değil, savunmasız ortak yazılım bağımlılığıdır.

Bilinen özellikleri

• Kitlesel istismara açık internet uygulamalarını seçme.
• Çok sayıda kurumu tek ürün zafiyeti üzerinden etkileyebilme.
• Bazı kampanyalarda şifreleme yerine veri hırsızlığı ve yayın tehdidine odaklanma.
• Tedarikçi ve alt müşteri bildirim zincirini zorlaştırma.

Büyük saldırıları

2023 MOVEit Transfer kampanyasında Cl0p, sıfır gün zafiyetini kullanarak çok sayıda kuruluştan veri çalmakla ilişkilendirildi. CISA/FBI ortak uyarısı olayın teknik göstergelerini ve azaltımlarını yayımladı. S31 Bu kampanya, “ransomware olayı” ifadesinin mutlaka uç nokta şifrelemesi anlamına gelmediğini gösterdi.

Durumu

Aktif; veri gaspı ağırlıklı. “RaaS” etiketi, her kampanyada aynı affiliate modelinin kullanıldığı veya şifreleme yapıldığı anlamına gelmez.

Savunma dersi

Dosya aktarım, yönetim ve sınır uygulamalarını kritik dış yüzey olarak envantere alın. Sıfır gün senaryosunda üretici yaması beklenirken devre dışı bırakma, erişim kısıtlama, günlük inceleme ve etkilenmiş sürüm avı için karar planınız olsun.

Akira

Ortaya çıkışı

Akira 2023'te görünür oldu ve kısa sürede geniş sektör kapsamı, çoklu platform etkisi ve bağlı kuruluş karakteriyle öne çıktı. CISA, FBI, Europol EC3 ve Hollanda NCSC 2024'te ortak uyarı yayımladı. S32

Faaliyet yılları

2023–2026. FBI'nin 2025 şikâyet verilerinde en çok bildirilen ransomware varyantları arasında üst sırada yer aldı. S10

Hedef sektörler

KOBİ'lerden büyük kuruluşlara; eğitim, finans, sağlık, imalat, profesyonel hizmet ve kritik altyapıya uzanan geniş hedef kümesi.

Bilinen özellikleri

• Uzak erişim ve geçerli hesap riskleriyle ilişkilendirilen operasyonlar.
• Windows yanında Linux/sanallaştırma iş yüklerini etkileyebilme.
• Veri hırsızlığı ve şifrelemeyi birleştiren çift gasp.
• Bağlı kuruluşa göre değişen araç ve yöntemler.

Büyük saldırıları ve ölçek

Resmî ortak uyarı, 2024 başına kadar yüzlerce kuruluşun etkilendiğini ve yüz milyonlarca dolarlık fidye talebi/ödemesi iddialarını değerlendirir. FBI 2025 verisi Akira'nın raporlanan şikâyetlerde yüksek görünürlüğünü sürdürdüğünü gösterir. Bu sayılar küresel kesin mağdur sayısı değildir. S10 S32

Durumu

Aktif. Güncel savunma, tek hash veya dosya uzantısına değil kimlik, VPN, ayrıcalık, hipervizör ve yedek davranışlarına dayanmalıdır.

Savunma dersi

Uzak erişim hesabı ile sanallaştırma/backup yönetimi arasında doğrudan güven yolu bırakmayın; phishing-resistant MFA, yönetim segmenti ve ayrı kimlik zinciri uygulayın.

Black Basta

Ortaya çıkışı

Black Basta 2022'de görünür oldu. CISA, FBI, HHS ve MS-ISAC 2024'te ortak uyarı yayımlayarak faaliyetlerinin özellikle kritik altyapı ve sağlık açısından riskini belgeledi. S33

Faaliyet yılları

2022–2025 döneminde resmî kayıtlarda güçlü görünürlük vardır. 2025 yargı kayıtları, Qakbot erişim ekosistemi ile Black Basta dâhil çeşitli ransomware aktörleri arasındaki iş bölümünü açıklar. 2026 kesim tarihinde markanın operasyonel sürekliliği açık kamu kanıtında belirsiz/düşük görünürlüklü olarak değerlendirilmelidir; “tamamen kapandı” veya “kesin aktif” demek için yeterli birincil kanıt yoktur. S62

Hedef sektörler

Sağlık, imalat, kamu, profesyonel hizmet, teknoloji ve kritik altyapı.

Bilinen özellikleri

• Veri hırsızlığı ve şifreleme yoluyla çift gasp.
• Erişim sağlayıcıları ve başka suç araçlarıyla ekosistem ilişkisi.
• E-posta/yardım masası baskısı ve meşru uzaktan yönetim araçlarının kötüye kullanıldığı kampanyalarla ilişkilendirilme.
• Özellikle sağlıkta hizmet kesintisi riski.

Büyük saldırıları ve ölçek

2024 CISA ortak uyarısı, Black Basta iştiraklerinin Nisan 2022 ile Mayıs 2024 arasında Kuzey Amerika, Avrupa ve Avustralya'da 500'den fazla kuruluşu ve ABD'nin 16 kritik altyapı sektörünün 12'sini etkilediğini bildirdi. S33

Durumu

Sürekliliği belirsiz. Resmî kayıtlarda tarihsel etkisi doğrulanmıştır; fakat 2026 güncel organizasyon yapısı açık kaynakta kesin değildir. Bu belirsizlik, savunma kontrollerini azaltma gerekçesi değildir.

Savunma dersi

Yardım masası kimlik doğrulamasını, toplu e-posta/arama baskısı altında dahi atlanmayacak güvenlik kontrolü hâline getirin. Yeni uzak yönetim aracı ve MFA sıfırlaması birlikte görülürse yüksek öncelikli olay üretin.

Play

Ortaya çıkışı

Play (Playcrypt) 2022'de görünür oldu. Kapalı grup veya sınırlı ortaklık karakteri gösterse de savunma literatüründe ransomware aktörü olarak önemli yer tutar; her kaynak onu klasik açık kayıtlı RaaS programı olarak sınıflandırmaz. Bu ayrım özellikle terminoloji doğruluğu için önemlidir.

Faaliyet yılları

2022–2026. CISA/FBI/ASD uyarısı Haziran 2025'te güncellendi ve FBI'ın Mayıs 2025 itibarıyla yaklaşık 900 etkilenmiş kuruluştan haberdar olduğu belirtildi. S34

Hedef sektörler

Kamu, sağlık, imalat, finans, eğitim ve profesyonel hizmetler; Kuzey/Güney Amerika ve Avrupa'da geniş coğrafya.

Bilinen özellikleri

• Geçerli hesap ve internete açık uygulama risklerinden yararlanma.
• Her olay için yeniden derlenen örneklerle salt hash tabanlı tespiti zorlaştırma.
• Veri hırsızlığı ve şifreleme yoluyla çift gasp.
• Kapalı/denetimli iştirak yapısına ilişkin değerlendirmeler.

Büyük saldırıları ve ölçek

Tek bir sembolik olaydan çok süreklilik ve hacimle öne çıkar. Resmî uyarı, 2024'te en aktif gruplar arasında olduğunu ve Mayıs 2025'e kadar yaklaşık 900 etkilenmiş kuruluşun FBI tarafından bilindiğini aktarır. S34

Durumu

Aktif. IOC'ler güncellenebilir, fakat benzersiz örnek üretimi nedeniyle davranış, kimlik ve yönetim düzlemi analizi kritik kalır.

Savunma dersi

KEV öncelikli yama, MFA, çevrimdışı yedek ve davranışsal izleme birlikte uygulanmalıdır; yalnızca antivirüs imzasına güvenilmemelidir.

DragonForce

Ortaya çıkışı

DragonForce 2023'te görünür oldu; 2024–2026 döneminde RaaS programı ve “kartel” markasıyla bağlı kuruluş toplamaya çalıştı. Belçika CCB, Mayıs 2026 raporunda onu hızla büyüyen, finansal motivasyonlu RaaS operatörü olarak değerlendirdi. S36

Faaliyet yılları

2023–2026 ve kesim tarihinde aktif.

Hedef sektörler

İmalat, iş hizmetleri, teknoloji, inşaat ve sağlık öne çıkar; ABD başlıca hedeflerden biri olarak değerlendirilir. CCB raporu 30'dan fazla ülkede 400'den fazla kompromize kuruluş değerlendirmesi sunar; bu sayı raporun yöntem ve doğrulama sınırları içinde okunmalıdır. S36

Bilinen özellikleri

• Bağlı kuruluşları ortak altyapı altında toplamaya dönük RaaS modeli.
• Şifreleme ile veri hırsızlığını birleştiren çift gasp.
• Başka markaların bağlı kuruluşlarını çekme veya “kartel”e katma iddiaları.
• Marka büyüklüğünü suç pazarlaması olarak öne çıkarma.

Büyük saldırıları ve ölçek

2025 Birleşik Krallık perakende olayları kamuya açık değerlendirmelerde DragonForce/bağlı aktörlerle ilişkilendirildi; her mağdur kurum aktör adını doğrulamadığı için grup iddiası ile mağdur açıklaması ayrılmalıdır. CCB'nin 2026 raporu, iki Belçika kuruluşu dâhil 400'den fazla küresel kompromize kuruluş değerlendirmesi verir. S36

Durumu

Aktif ve büyüyen. “Kartel” tek komuta kanıtı değildir; marka, altyapı ve iştirak ilişkisinin olaya göre doğrulanması gerekir.

Savunma dersi

Bağlı kuruluş göçünü tehdit istihbaratına yansıtın. Eski RansomHub/BlackLock göstergeleri ile DragonForce davranışlarını ayrı silo yerine ortak kimlik, erişim ve veri hipotezlerinde arayın.

Medusa

Ortaya çıkışı

Medusa adı 2021–2022 döneminde görünürlük kazandı; başka “Medusa” adlarıyla karıştırılmamalıdır. CISA, FBI ve MS-ISAC Mart 2025'te ortak #StopRansomware uyarısı yayımladı. S35

Faaliyet yılları

2021/2022–2026 ve kesim tarihinde aktif.

Hedef sektörler

Sağlık, eğitim, hukuk, sigorta, teknoloji, imalat ve diğer kritik altyapı sektörleri.

Bilinen özellikleri

• Veri hırsızlığı ile şifreleme baskısını birleştirme.
• İnternete açık hizmet, geçerli hesap ve uzaktan erişim riskleriyle ilişkilendirilen olaylar.
• Mağdurla doğrudan iletişim ve veri yayın baskısı.
• Geniş sektör ve coğrafya.

Büyük saldırıları ve ölçek

2025 ortak uyarısı, Şubat 2025 itibarıyla Medusa geliştiricileri ve bağlı kuruluşlarının 300'den fazla kritik altyapı sektörü mağdurunu etkilediğini bildirdi. Bu, doğrulanan her küresel olayın eksiksiz sayımı değildir. S35

Durumu

Aktif. FBI 2025 raporunda da en çok bildirilen varyantlar arasında yer alır. S10

Savunma dersi

İnternete açık sistem yaması, MFA, çevrimdışı/değiştirilemez yedek, ağ segmentasyonu ve olağandışı veri çıkışını asgari ortak taban hâline getirin.

Diğer güncel ve önemli yapılar

Qilin

FBI 2025 verisinde en görünür varyantlardan biridir ve Synnovis olayı kamuya açık değerlendirmelerde Qilin ile ilişkilendirilmiştir. NHS olayı ve etkileri doğrular; aktör atfı resmî NHS kaydının merkezinde değildir. Bu nedenle “Qilin üstlendi/ilişkilendirildi” ile “NHS doğruladı” ifadeleri ayrılmalıdır. S10 S54

RansomHub

2024'te çok sayıda sektörde görülen RaaS yapısı için CISA/FBI/HHS/MS-ISAC ortak uyarısı yayımlandı. 2025–2026 kaynakları iştiraklerin başka markalara kaydığını ve DragonForce'un RansomHub ekosistemini çektiğini değerlendirir; tam birleşme varsayılmamalıdır. S38 S36

BlackSuit / Royal

Royal ile BlackSuit arasında kamu kurumlarınca süreklilik kuruldu. Temmuz 2025'te uluslararası operasyonla dört sunucu ve dokuz alan adı ele geçirildi; DOJ Ağustos 2025'te eylemi açıkladı. Bu bozma faaliyet kapasitesini düşürür, fakat eski erişimlerin başka aktörlere taşınma riskini ortadan kaldırmaz. S58

Interlock

Eylül 2024'ten itibaren geniş sektörlerde faaliyet gösteren Interlock için Temmuz 2025'te ortak CISA/FBI/HHS/MS-ISAC uyarısı yayımlandı. Kesim tarihinde savunma ekiplerinin takip etmesi gereken güncel yapılardan biridir. S39

INC/Lynx/Sinobi ve SafePay

FBI 2025 şikâyet sıralamasında INC/Lynx/Sinobi ve SafePay adları ilk on içinde yer aldı. Bu adların aynı soy ağacına ilişkin iddiaları, olay bazında teknik ve yargısal kanıtla değerlendirilmelidir; ad benzerliği veya sızıntı sitesi beyanı tek başına örgütsel süreklilik kanıtı değildir. S10

Gruplar arasında karşılaştırma yaparken kullanılacak altı soru

1. Ad, yazılım ailesini mi yoksa gerçek operatör çekirdeğini mi ifade ediyor?
2. Faaliyet resmî olay kaydıyla mı, DLS iddiasıyla mı ölçülüyor?
3. Şifreleme var mı, yalnızca veri hırsızlığı mı, yoksa ikisi de mi?
4. İlk erişimi aynı aktör mü sağladı, yoksa IAB/başka bağlı kuruluş mu?
5. Kesim tarihinde marka aktif mi, bozulmuş mu, kapalı mı, yoksa belirsiz mi?
6. Savunma ekibi markaya özgü IOC'nin ötesinde hangi davranış ve kontrol boşluğunu izliyor?

RaaS açısından neden önemli?

RaaS savunmasında grup listesi amaç değil, ekosistem davranışını anlamak için araçtır. Bu bölüm; markaların doğuş, hedef, ölçek ve durumunu aynı şablonla karşılaştırıp doğrulanmış olay ile fail iddiasını ayırır. Böylece kurumlar “son popüler grup” peşinde koşmak yerine tekrar eden kimlik, erişim, veri ve kurtarma zayıflıklarına yatırım yapabilir.

Dünyayı Değiştiren Büyük RaaS Olayları

Vaka inceleme yöntemi

Her vaka aynı şablonla ele alınır: tarih ve hedef; doğrulanan etki; iş/hizmet kaybı; kamuya açıklanan mali sonuç; atıf güveni; dersler; bugün tekrarlanma olasılığı. Kamuya açıklanmayan rakamlar tahminle doldurulmaz. Fidye miktarı toplam maliyet, toplam maliyet de mutlaka nakit çıkışı değildir.

Hızlı karşılaştırma

Olay 1 – Colonial Pipeline

Olayın adı, tarih, ülke ve hedef kurum

Colonial Pipeline siber olayı — 7 Mayıs 2021, ABD. Hedef, ABD Doğu Yakası yakıt tedarikinde kritik rol oynayan Colonial Pipeline'ın iş ağıydı. Şirket, iş sistemlerindeki ransomware etkisini sınırlamak amacıyla boru hattı operasyonlarını önlem olarak durdurdu. Kamu kayıtları operasyonel teknoloji sistemlerinin doğrudan şifrelendiğini kanıtlamaz; “pipeline hacklendi ve fiziksel kontrol ele geçirildi” ifadesi bu nedenle fazla kesindir. S40

RaaS bağlantısı ve atıf

DOJ, olayı DarkSide ransomware operasyonuyla ilişkilendirdi ve ödenen fidyenin bir kısmına el koydu. DarkSide kamu değerlendirmelerinde RaaS modeliyle çalışan yapı olarak tanımlandı. S41

Saldırının etkisi

İş ağına yönelik olay, faturalama ve operasyon güveni gibi bağımlılıklar nedeniyle fiziksel yakıt akışının durdurulmasına yol açtı. Etkinin kritik dersi, OT'nin mutlaka ele geçirilmiş olması değil; BT sistemlerinin güvenilmez hâle gelmesinin operasyonu güvenli biçimde sürdürmeyi imkânsızlaştırabilmesidir.

İş kaybı

Operasyonlar 7 Mayıs'ta durdu; şirket 12 Mayıs'ta yeniden başlatmayı duyurdu ve 13 Mayıs'a doğru ürün teslimatını normalleştirmeye başladı. Yaklaşık altı günlük kesinti boyunca bazı bölgelerde yakıt kıtlığı ve panik alımları yaşandı.

Finansal zarar

Şirket yaklaşık 4,4 milyon ABD doları değerinde fidye ödediğini açıkladı; DOJ yaklaşık 2,3 milyon ABD doları karşılığı kripto varlığı daha sonra ele geçirdi. Kurtarılan tutar, toplam olay maliyetinin veya tüm ödemenin geri alındığı anlamına gelmez. Kesinti, müdahale ve piyasa etkisinin toplamı kamu kayıtlarında tek bir kesin rakam değildir. S41

Kamu hizmetlerine etkisi

Yakıt dağıtımı yavaşladı; bazı eyaletlerde acil durum önlemleri ve tedarik esneklikleri devreye alındı. Olay, özel bir şirketteki RaaS etkisinin hızla ulusal enerji güvenliği ve kamu davranışı sorununa dönüşebileceğini gösterdi.

Olaydan çıkarılan dersler

• BT–OT bağımlılığı ve güvenli durdurma karar ölçütleri önceden belgelenmelidir.
• Faturalama, stok, planlama ve iletişim gibi “iş” sistemleri kritik operasyon bileşenidir.
• Ayrıcalıklı uzaktan erişim, eski hesap ve MFA istisnaları düzenli doğrulanmalıdır.
• Manuel operasyon modu, yakıt/lojistik/veri doğruluğu ve insan güvenliğiyle birlikte tatbik edilmelidir.
• Kollukla erken iş birliği para akışının ve altyapının izlenmesine katkı sağlayabilir.

Bugün aynı olay tekrar yaşanabilir mi?

Evet. Enerji şirketleri segmentasyon ve düzenleyici baskıyı geliştirmiş olsa da kimlik, tedarikçi erişimi ve BT–OT bağımlılığı sürmektedir. Tekrarı önlemenin ölçütü “OT internete bağlı değil” değil; iş ağı kaybında operasyonun güvenle sürdürülebilmesi ve yönetim yollarının birbirinden ayrılmasıdır.

Olay 2 – JBS Foods

Olayın adı, tarih, ülke ve hedef kurum

JBS siber saldırısı — 30 Mayıs 2021 civarı; ABD merkezli küresel et/gıda üretim operasyonları. JBS'nin Kuzey Amerika ve Avustralya'daki bazı BT sistemleri ve üretim operasyonları etkilendi.

RaaS bağlantısı ve atıf

FBI, olayı Sodinokibi/REvil'e atfetti. Bu, yalnızca failin iddiasına değil resmî kolluk değerlendirmesine dayanır. S42

Saldırının etkisi

Şirket belirli sunucuları kapattı, et işleme tesislerinde vardiya/üretim kesintileri oluştu ve küresel gıda tedarik zinciri riski gündeme geldi. Yedek sistemlerin etkilenmediği ve hızlı toparlanmayı desteklediği şirket açıklamalarına yansıdı.

İş kaybı

Kesinti birkaç gün içinde büyük ölçüde giderildi; ancak üretim hattında saatler bile hayvan tedariki, soğuk zincir, çalışan vardiyası ve dağıtım planı üzerinde geniş etki oluşturabilir.

Finansal zarar

JBS, sistemlerine ve verilere ilişkin belirsizlik nedeniyle 11 milyon ABD doları eşdeğerinde ödeme yaptığını açıkladı. Bu rakam toplam olay maliyeti değildir; üretim kaybı, müdahale ve iyileştirme giderleri ayrıca oluşmuştur. S43

Kamu hizmetlerine etkisi

Doğrudan bir kamu kurumu etkilenmedi; fakat gıda tedariki kritik toplumsal işlevdir. Kesintinin uzaması fiyat, tedarik ve iş gücü zincirini etkileyebilirdi.

Olaydan çıkarılan dersler

• Üretim ile kurumsal BT arasındaki bağımlılık haritalanmalıdır.
• Yedeklerin saldırı alanından ayrılması toparlanma süresini belirgin kısaltabilir.
• Tesislerin güvenli manuel/degrade modda çalışması önceden planlanmalıdır.
• Ödeme, kurtarma yeterliliğinin yerine geçmez ve toplam maliyeti göstermez.

Bugün aynı olay tekrar yaşanabilir mi?

Evet. Gıda üretimi zaman, soğuk zincir ve fiziksel süreç bakımından kesintiye duyarlıdır. Çok tesisli yapı, merkezi kimlik veya planlama sistemi üzerinden ortak hata alanı yaratabilir.

Olay 3 – Kaseya VSA

Olayın adı, tarih, ülke ve hedef kurum

Kaseya VSA tedarik zinciri olayı — 2 Temmuz 2021, ABD merkezli ve küresel alt müşteri etkili. Kaseya'nın uzaktan yönetim ürünü VSA'yı şirket içinde barındıran belirli müşteriler ve onların yönettiği alt kuruluşlar etkilendi.

RaaS bağlantısı ve atıf

Olay REvil ile ilişkilendirildi; DOJ daha sonra bir bağlı kuruluşun Kaseya olayı dâhil ransomware saldırılarındaki rolüne ilişkin tutuklama ve suçlama sürecini açıkladı. S45

Saldırının etkisi

Merkezi yönetim yazılımı üzerinden zararlı işlem dağıtılması, MSP modelindeki bir erişimin çok sayıda alt kuruma yayılabileceğini gösterdi. Kaseya, yaklaşık 50 doğrudan müşterinin etkilendiğini bildirdi. Basında yer alan “1.500'e kadar işletme” tahminleri aşağı akış müşterilerini içerir; doğrudan Kaseya müşteri sayısıyla aynı ölçü değildir. S44

İş kaybı

Etkilenen MSP'ler ve alt müşteriler, sistemlerini korumak için VSA'yı kapattı veya hizmetleri manuel yürüttü. Kesinti süresi kuruluşa göre değişti; tek bir küresel süre yoktur.

Finansal zarar

Toplam doğrulanmış küresel zarar tek rakam olarak kamuya açıklanmadı. Olay; dış müdahale, iş kesintisi, müşteri desteği ve güven kaybı yarattı. Failin kamuya açık fidye talepleri, ödenmiş toplam tutar olarak kabul edilemez.

Kamu hizmetlerine etkisi

Alt müşteriler arasında perakende ve yerel hizmet işletmeleri bulundu; bazı kuruluşlar satış ve kasa süreçlerini durdurdu. Asıl kamu dersi, yönetilen hizmet sağlayıcının çok sayıda küçük kurum için ortak kritik bağımlılık olmasıdır.

Olaydan çıkarılan dersler

• RMM ve yazılım dağıtım sistemi “yüksek etkili yönetim düzlemi” olarak sınıflandırılmalıdır.
• Tedarikçi güncellemesine güven, davranışsal dağıtım sınırlarını ortadan kaldırmamalıdır.
• MSP'nin müşteri ortamlarına erişimi birbirinden ve kendi kurumsal ağından ayrılmalıdır.
• Acil kapatma, gösterge paylaşımı ve müşteri iletişimi sözleşmede tanımlanmalıdır.
• Doğrudan müşteri, alt müşteri ve etkilenmiş uç nokta sayıları ayrı raporlanmalıdır.

Bugün aynı olay tekrar yaşanabilir mi?

Evet. RMM, kimlik sağlayıcı, dosya aktarım ürünü, bulut platformu ve MSP'ler ortak hata alanı yaratmaya devam ediyor. Secure-by-design yaklaşımı, müşteri izolasyonu ve hızlı toplu iptal mekanizması kritik kalır.

Olay 4 – Caesars Entertainment

Olayın adı, tarih, ülke ve hedef kurum

Caesars Entertainment veri güvenliği olayı — Eylül 2023, ABD. Caesars, dış kaynaklı bir BT destek sağlayıcısına yönelik sosyal mühendislik sonucunda sadakat programı veri tabanının bir kopyasının alındığını SEC'e bildirdi. S47

RaaS bağlantısı ve atıf

Kamuya açık araştırmalar olayı Scattered Spider/ALPHV ekosistemiyle ilişkilendirdi. Ancak Caesars'ın SEC bildirimi aktörü adlandırmaz. Bu nedenle rehber, aktör bağlantısını “güçlü kamu atfı” olarak etiketler; şirketçe doğrulanmış atıf saymaz.

Saldırının etkisi

Sadakat programı üyelerine ait sürücü belgesi ve/veya sosyal güvenlik numarası gibi verilerin bir kısmı etkilenmiş olabilir. Şirket, müşteriyle yüz yüze operasyonların etkilenmediğini ve veri silme taahhüdünü doğrulayamayacağını açıkça belirtti. S47

İş kaybı

MGM olayından farklı olarak Caesars, fiziksel işletme operasyonlarında kesinti bildirmedi. Bu karşıtlık, benzer dönemde benzer kamu atfı olsa bile iki olayın tek “Las Vegas saldırısı” olmadığını gösterir.

Finansal zarar

Şirket SEC bildiriminde olayın faaliyet sonuçları ve mali durumu üzerinde maddi etki yaratmasını beklemediğini belirtti. Basında geçen ödeme miktarları şirketin düzenleyici bildiriminde doğrulanmadı; bu rehber bunları olgu olarak kullanmaz.

Kamu hizmetlerine etkisi

Kamu hizmeti kesilmedi. Bununla birlikte kimlik verisi sızıntısı dolandırıcılık ve uzun süreli mağduriyet riski doğurur.

Olaydan çıkarılan dersler

• Dış kaynak destek sağlayıcısı, kurumun kimlik güven zincirinin parçasıdır.
• Yardım masası doğrulaması bilgi sorularına değil güçlü cihaz/kimlik kanıtına dayanmalıdır.
• Veri sızıntısı, operasyon kesintisi olmadan da ciddi olaydır.
• Suçlunun “veriyi sildim” beyanı bağımsız doğrulanamaz.

Bugün aynı olay tekrar yaşanabilir mi?

Evet. İnsan odaklı kimlik kurtarma ve tedarikçi destek süreçleri, modern phishing-resistant MFA'nın etrafından dolaşılabilecek zayıf halka olabilir.

Olay 5 – MGM Resorts

Olayın adı, tarih, ülke ve hedef kurum

MGM Resorts siber güvenlik olayı — Eylül 2023, ABD. Otel rezervasyonları, dijital oda anahtarları, ödeme ve bazı casino/kurumsal sistemler günler süren kesinti yaşadı.

RaaS bağlantısı ve atıf

Olay, güvenilir kamu kaynaklarında Scattered Spider ile ALPHV/BlackCat ekosistemine bağlandı. CISA, Scattered Spider'ın yardım masası ve kimlik süreçlerine odaklanan davranışları için ortak uyarı yayımladı. MGM'nin SEC bildirimi belirli fail adını kullanmaz; atıf bu nedenle şirket tarafından doğrulanmış değildir. S46 S61

Saldırının etkisi

MGM bazı sistemleri koruma amacıyla kapattı; otel ve casino operasyonlarında manuel süreçlere dönüldü. Şirket, belirli müşterilere ait kişisel verilerin de alındığını bildirdi.

İş kaybı

Operasyonel aksama yaklaşık on gün civarında yoğun hissedildi; sistem ve süreçlerin tümünün normalleşmesi daha uzun sürdü. Etki yalnızca “web sitesi kapalı” değildi; fiziksel müşteri deneyimi ve çalışan iş akışları doğrudan etkilendi.

Finansal zarar

MGM, Eylül 2023 olayının üçüncü çeyrek sonuçlarında yaklaşık 100 milyon ABD doları olumsuz düzeltilmiş Property EBITDAR etkisi ve 10 milyon ABD dolarından düşük tek seferlik gider yarattığını bildirdi. Bu iki kalem farklı ölçülerdir ve birbirine körlemesine eklenmemelidir. S46

Kamu hizmetlerine etkisi

Kritik kamu hizmeti kesilmedi; ancak büyük konaklama işletmesindeki kesinti, şehir ekonomisi, çalışanlar, etkinlikler ve müşteri güveni üzerinde görünür etki yarattı.

Olaydan çıkarılan dersler

• Yardım masası, ayrıcalıklı kimlik kurtarmada Tier-0 güvenlik kontrolüdür.
• Fiziksel işletmeler için dijital anahtar, POS, rezervasyon ve kimlik sistemlerinin manuel alternatifi test edilmelidir.
• Saldırganı sistemden çıkarmak için kontrollü kapatma doğru olabilir; bunun iş etkisi önceden modellenmelidir.
• Kamu atfı ile şirketin doğruladığı veri ve mali etki ayrı yazılmalıdır.

Bugün aynı olay tekrar yaşanabilir mi?

Evet. Konaklama, yüksek çalışan devri, geniş tedarikçi ağı, 7/24 operasyon ve müşteri verisi nedeniyle kimlik odaklı RaaS iştirakleri için çekicidir.

Olay 6 – Change Healthcare

Olayın adı, tarih, ülke ve hedef kurum

Change Healthcare siber saldırısı — 21 Şubat 2024, ABD. UnitedHealth Group'un Change Healthcare birimi; eczane, sigorta uygunluğu, tıbbi talep ve ödeme işlemlerinde çok geniş bir sağlık ekosistemi bağımlılığına sahipti.

RaaS bağlantısı ve atıf

Kongre kayıtları ve kamu açıklamaları olayı ALPHV/BlackCat bağlı kuruluşuyla ilişkilendirdi. Ele geçirilmiş kimlik bilgisiyle, MFA uygulanmayan eski bir Citrix portalından erişim sağlandığı açıklandı. S50

Saldırının etkisi

Eczane reçete işleme, sağlık talebi iletimi, ödeme ve kurumların nakit akışı ciddi biçimde bozuldu. Veri hırsızlığı çok genişti; HHS bildirim süreci yüz milyonlarca kişilik ölçeğe ulaştı. Kişi sayısı olay araştırması ve birleştirilmiş bildirimler ilerledikçe değişti; bu nedenle tarih etiketiyle okunmalıdır. S48

İş kaybı

Temel hizmetler kademeli geri döndü, fakat bazı işlem hacimleri ve sağlayıcı etkisi aylar sürdü. Olay, tek bir takas/ödeme aracısının sağlık ekosisteminde sistemik “yoğunlaşma riski” yaratabileceğini gösterdi.

Finansal zarar

UnitedHealth 2024 Form 10-K'da 2,2 milyar ABD doları doğrudan müdahale maliyeti ve 867 milyon ABD doları tahmini iş kesintisi etkisi bildirdi. Doğrudan müdahale maliyetine faizsiz kredi desteği, ağ restorasyonu ve etkilenen kişilere bildirim gibi kalemler dâhildir. Bunlar farklı muhasebe kategorileridir. S49

Kamu hizmetlerine etkisi

Hastane, klinik, eczane ve hekim gruplarının talep ve ödeme süreçleri aksadı. UnitedHealth, sağlayıcılara 9 milyar ABD dolarını aşan faizsiz destek sağladığını Kongreye bildirdi; bu rakam zarar değil, ekosistemin nakit akışı krizini hafifletmek için verilen destektir. S50

Olaydan çıkarılan dersler

• “Eski” erişim yolu MFA ve cihaz güveninden muaf bırakılamaz.
• Sağlıkta üçüncü taraf yoğunlaşma ve alternatif işlem kanalı iş sürekliliği planına girmelidir.
• Kimlik ihlali sonrası yalnızca parola değil oturum, cihaz ve ayrıcalık zinciri yenilenmelidir.
• Veri ihlali bildirimi, teknik sistemler geri döndükten çok sonra sürebilir.
• Tedarikçi risk yönetimi anketle sınırlı kalmamalı; kesinti tatbikatı ve veri akışı görünürlüğü içermelidir.

Bugün aynı olay tekrar yaşanabilir mi?

Evet. Sağlık işlemleri az sayıdaki ara platforma bağımlıdır ve eski sistemler/istisnalar bulunabilir. En etkili önleme; phishing-resistant MFA, eski erişim kapatma, ayrıcalıklı yönetim ayrımı, ağ segmentasyonu ve alternatif işlem planıdır.

Olay 7 – CDK Global

Olayın adı, tarih, ülke ve hedef kurum

CDK Global siber olayı — 19 Haziran 2024, ABD ve Kanada ağırlıklı otomotiv bayileri. CDK'nin bayi yönetim sistemi; satış, servis, envanter, müşteri ilişkileri ve muhasebe gibi çekirdek işlevleri destekliyordu.

RaaS bağlantısı ve atıf

ABD ulusal istihbarat değerlendirmesi olayı BlackSuit bağlamında ele aldı. CDK ve etkilenen halka açık bayilerin düzenleyici bildirimleri hizmet kesintisini doğrular; saldırgan ayrıntıları her şirket bildiriminde yer almaz. S53

Saldırının etkisi

Binlerce bayi dijital satış ve servis süreçlerini manuel forma, telefon ve geçici iş akışlarına çevirdi. Ortak platform bağımlılığı, tek sağlayıcı kesintisinin çok sayıda bağımsız işletmeyi aynı anda etkileyebileceğini gösterdi.

İş kaybı

AutoNation, temel DMS işlevlerinin 29 Haziran'da geri geldiğini; bazı yardımcı sistem ve entegrasyonların Temmuz sonuna kadar toparlandığını bildirdi. Kesinti satış, servis, stok, CRM, muhasebe ve çalışan verimliliğini etkiledi. S52

Finansal zarar

Sonic Automotive, 2024 ikinci çeyreğinde vergi öncesi gelirin yaklaşık 30 milyon ABD doları olumsuz etkilendiğini bildirdi. AutoNation, aynı çeyrekte hisse başına kazanç üzerinde yaklaşık 1,55 ABD doları olumsuz etki tahmin etti ve iş sürekliliği için komisyon bazlı çalışanlara yaklaşık 43 milyon ABD doları tek seferlik tazminat ödedi. Bu rakamlar iki ayrı şirketin etkisidir; CDK olayının toplam küresel zararı değildir. S51 S52

Kamu hizmetlerine etkisi

Kamu kurumu hizmeti kesilmedi; ancak araç satışı, bakım, parça, sigorta/finansman ve tüketici işlemleri aksadı. Ulaşım ekonomisine bağlı geniş bir ticari hizmet zinciri etkilendi.

Olaydan çıkarılan dersler

• SaaS/DMS kesintisinde bayinin hangi temel işlemleri yasal ve güvenli biçimde manuel yapacağı belirlenmelidir.
• Sağlayıcıdan veri dışa aktarma, alternatif erişim ve kesinti iletişim SLA'sı sözleşmeye konmalıdır.
• İş sürekliliği yalnızca BT kurtarma değildir; çalışan ücretleri, müşteri onayı, muhasebe kontrolü ve sahtecilik önleme gerekir.
• Üçüncü taraf olayının mali etkisi müşterilerde ayrı ayrı ve çok daha büyük olabilir.

Bugün aynı olay tekrar yaşanabilir mi?

Evet. Sektörel dikey yazılımlar çok sayıda işlemi tek platformda toplar. Alternatif sağlayıcıya anında geçiş genellikle mümkün değildir; veri taşınabilirliği ve manuel asgari çalışma modu zorunludur.

Olay 8 – Synnovis

Olayın adı, tarih, ülke ve hedef kurum

Synnovis ransomware saldırısı — 3 Haziran 2024, Birleşik Krallık. Synnovis, Güneydoğu Londra'daki NHS kuruluşları için kan, idrar ve doku örneği dâhil patoloji hizmetleri sunan ortak girişimdir. S54

RaaS bağlantısı ve atıf

NHS olayı ransomware olarak doğruladı. Qilin markası kamuya açık biçimde olayı üstlendi ve araştırmalarda ilişkilendirildi; NHS'nin temel vaka kaydı aktör adını resmî atıf olarak kullanmaz. Bu nedenle etkiler doğrulanmış, Qilin bağlantısı ise kamu atfı/iddiası olarak sunulur.

Saldırının etkisi

Patoloji test kapasitesi ciddi biçimde düştü. Kan grubu çapraz eşleştirme sistemleri etkilenince O tipi kan kullanımına daha fazla ihtiyaç doğdu; bu durum ulusal O tipi kan stok baskısına katkıda bulundu. Çalınan ve daha sonra yayımlanan dosyalar için uzun süren veri incelemesi yapıldı. S54

İş kaybı

NHS kayıtları en çok etkilenen kuruluşlarda 10.152 akut ayakta tedavi randevusu ve 1.710 elektif işlemin ertelendiğini; toplam gecikmenin 11.000'i aştığını bildirir. Hizmetler Aralık 2024'e kadar tamamen geri yüklendi. S54

Finansal zarar

Birleşik Krallık Parlamentosuna yapılan Kasım 2025 açıklaması Synnovis açısından tahmini finansal etkiyi 32,7 milyon sterlin olarak verdi. Bu rakam tüm NHS zincirindeki toplumsal ve klinik maliyeti kapsamak zorunda değildir. S55

Kamu hizmetlerine etkisi

Parlamento açıklaması saldırının beş NHS trustı ve yerel bakım sağlayıcılarında hizmet kesintisine yol açtığını ve trajik biçimde bir hastanın ölümüne katkıda bulunduğunu bildirdi. Nedensellik dili önemlidir: kayıt “tek başına ölüm nedeni” değil “katkıda bulundu” ifadesini kullanır. S55

Olaydan çıkarılan dersler

• Patoloji gibi görünmez tedarikçiler klinik bakımın kritik dijital altyapısıdır.
• Laboratuvar bilgi sistemi, çalışma sürücüsü ve hasta verisi kapsamı ayrı incelenmelidir.
• Kan, test ve acil işlem için bölgesel karşılıklı yardım önceden planlanmalıdır.
• Teknik geri dönüş ile birikmiş randevu/test yükünün giderilmesi farklı zaman çizelgeleridir.
• Klinik güvenlik, ransomware iş etki analizinde doğrudan insan zararı ölçütü olarak yer almalıdır.

Bugün aynı olay tekrar yaşanabilir mi?

Evet. Hastane dışı laboratuvar, görüntüleme, reçete ve lojistik sağlayıcıları klinik zincirin ortak hata alanlarıdır. Sağlık kurumları tedarikçiyi yalnızca veri işleyen taraf değil, hasta güvenliği bağımlılığı olarak değerlendirmelidir.

Olay 9 – Costa Rica kamu kurumları

Olayın adı, tarih, ülke ve hedef kurum

Costa Rica kamu sektörü ransomware krizi — Nisan–Mayıs 2022, Costa Rica. Maliye Bakanlığı başta olmak üzere vergi, gümrük, sosyal güvenlik ve başka kamu kurumları etkilendi.

RaaS bağlantısı ve atıf

İlk büyük saldırı dalgası Conti ile resmî olarak ilişkilendirildi. Ardından başka ransomware olayları da yaşandı; bütün 2022 kamu kesintilerini tek bir aktöre atfetmek doğru değildir. S56

Saldırının etkisi

Devlet gelir toplama ve dış ticaret süreçleri uzun süre aksadı; hükûmet ulusal acil durum ilan etti. Kurumlar manuel prosedürlere ve geçici sistemlere geçti.

İş kaybı

Dünya Bankası değerlendirmesi yaklaşık 26 kamu kuruluşunun etkilendiğini ve önemli hizmet kesintisinin yaklaşık 56 gün sürdüğünü belirtir. Kurum ve hizmet bazında toparlanma süreleri farklıdır. S56

Finansal zarar

Dünya Bankası, toplam zararı ülke GSYH'sinin yaklaşık yüzde 2,4'üne eşdeğer tahmin eden değerlendirmeyi aktarır. Bu oran doğrudan ödenmiş fatura değil; üretim, kamu geliri ve geniş ekonomik etkiyi modelleyen tahmindir. S56

Kamu hizmetlerine etkisi

Vergi ve gümrük işlemleri, sosyal güvenlik ve bazı kamu hizmetleri aksadı. İthalat/ihracat akışları ve kamu gelirleri etkilendi. IMF ülke değerlendirmesi olayı makroekonomik ve kurumsal dayanıklılık bağlamında ele aldı. S57

Olaydan çıkarılan dersler

• Ulusal olay komutası, kurumlar arası kimlik/iletişim ve öncelikli hizmet listesi önceden hazırlanmalıdır.
• Vergi, gümrük ve sosyal güvenlik için çevrimdışı/manual asgari hizmet modu gerekir.
• Kamu ağlarında ortak kimlik ve tedarikçi bağımlılıkları ulusal risk olarak yönetilmelidir.
• Uluslararası CERT, kolluk ve kalkınma kurumu desteği için hazır koordinasyon kanalı bulunmalıdır.
• Marka sona erse bile sızdırılmış erişim ve başka grupların fırsatçılığına karşı yoğun izleme sürmelidir.

Bugün aynı olay tekrar yaşanabilir mi?

Evet. Yerel ve merkezi yönetimler eski sistem, bütçe kısıtı, geniş hizmet yüzeyi ve yüksek kamu baskısı nedeniyle RaaS için çekici kalır. Ulusal yedekleme, ortak güvenli bulut, kimlik standardı ve kriz tatbikatı riski düşürür.

“Las Vegas saldırıları” neden tek vaka değildir?

Eylül 2023'te MGM ve Caesars'ın aynı şehir/sector bağlamında etkilenmesi, olayların tek bir ağ ihlali olduğu anlamına gelmez. Caesars veri sızıntısı bildirip tüketici operasyonlarının etkilenmediğini söyledi; MGM ise günler süren fiziksel/dijital operasyon kesintisi ve yaklaşık 100 milyon ABD doları etki bildirdi. Fail bağlantıları benzer kamu değerlendirmelerinde yer alsa da giriş, kapsam, zaman çizelgesi ve iş sonucu ayrıdır. S46 S47

Bu ayrım vaka analizinin temel kuralıdır: aynı marka, şehir veya tarihte gerçekleşen olaylar bağımsız delil setleriyle incelenir. Toplu etiket, kök neden ve kontrol dersini gizleyebilir.

Vakalar arası ortak örüntüler

RaaS açısından neden önemli?

Gerçek vakalar RaaS'ın yalnızca dosya şifrelemediğini; yakıt, gıda, sağlık, otomotiv, konaklama ve devlet hizmetlerinde zincirleme etki yarattığını kanıtlar. Standart şablon, sansasyonel fail anlatısı yerine doğrulanan etkiyi, kanıt güvenini ve tekrar riskini karşılaştırılabilir hâle getirir.

RaaS'ın Hedef Aldığı Kurumlar

Hedef olmayı belirleyen dört baskı çarpanı

RaaS bağlı kuruluşları çoğu zaman “en değerli veriye sahip sektör”den çok, aşağıdaki dört koşulun birleştiği kurumu seçer:

1. Kesinti pahalıdır: Hizmet saatler içinde gelir, insan güvenliği veya kamu düzeni kaybına dönüşür.
2. Veri hassastır: Hasta, öğrenci, müşteri, çalışan, fikrî mülkiyet veya devlet verisi yayın tehdidini güçlendirir.
3. Erişim yüzeyi geniştir: Eski sistem, çok sayıda lokasyon, tedarikçi, uzaktan erişim veya ortak hesap vardır.
4. Kurtarma karmaşıktır: Yedek olsa bile uygulama bağımlılıkları, özel cihazlar ve düzenleyici doğrulama toparlanmayı uzatır.

NCSC 2025 değerlendirmesi, çoğu siber suçlunun sektör bağımsız olduğunu; ödeme olasılığı, kesintiye hassasiyet ve sızdırılan verinin doğuracağı zarar üzerinden seçim yaptığını belirtir. S11 Dolayısıyla bu bölüm “yalnızca bu sektörler hedef olur” listesi değildir; baskı çarpanlarını sektör bağlamında açıklar.

Belediyeler ve yerel yönetimler

Neden hedef oluyorlar?

Belediyeler nüfus, vergi, ruhsat, imar, sosyal yardım, su, ulaşım, ödeme ve çalışan sistemlerini birlikte barındırır. Bütçe ve uzman personel sınırlıyken hizmet kesintisine kamu toleransı düşüktür. Çok sayıda saha lokasyonu, meclis/kurul erişimi, taşeron ve eski uygulama ortak kimlik alanına bağlı olabilir.

RaaS baskısı nasıl oluşur?

• Çevrimiçi ödeme, ruhsat ve belge hizmetinin durması kamu tepkisi yaratır.
• Vatandaş verisinin sızması bildirim ve dolandırıcılık riskini artırır.
• Kamu kayıtlarının bütünlüğü bozulursa yalnızca erişilebilirlik değil hukuki güven etkilenir.
• Seçim, bütçe kapanışı veya afet dönemi zaman baskısını büyütür.

Öncelikli savunma

• Gelir/ruhsat/sosyal yardım gibi kritik hizmetler için çevrimdışı doğrulama ve manuel asgari süreç.
• Belediye ağı ile su, ulaşım, kamera ve diğer operasyonel sistemler arasında güçlü ayrım.
• Merkezi kimlikte phishing-resistant MFA; seçilmiş yetkili ve taşeron hesaplarında süreli erişim.
• Değiştirilemez yedek yanında kayıt bütünlüğü ve geri yükleme sırası testi.
• Ulusal/yerel CERT, kolluk, vali/kaymakamlık ve hizmet tedarikçileriyle kriz iletişim planı.

Hastaneler, klinikler ve laboratuvarlar

Neden hedef oluyorlar?

Sağlık kuruluşlarında sistem kesintisi doğrudan hasta güvenliği, test, ilaç, görüntüleme, ameliyat ve sevk süresini etkileyebilir. Veriler hem çok hassastır hem uzun süreli kimlik/dolandırıcılık riski taşır. Tıbbi cihazlar, laboratuvar sistemleri ve eski uygulamalar hızlı yama veya değişim için sınırlı olabilir.

RaaS baskısı nasıl oluşur?

• EHR, e-reçete, laboratuvar veya radyoloji erişimi kesilince klinik karar yavaşlar.
• Hasta verisi sızıntısı etik, hukuki ve kişisel zarar baskısı doğurur.
• Bölgesel laboratuvar veya ödeme sağlayıcısı çok sayıda kurumu aynı anda etkiler.
• Hasta randevusu ve örnek birikimi, teknik sistem açıldıktan sonra da hizmet kaybını sürdürür.

Change Healthcare ve Synnovis vakaları, “sağlık tedarikçisi”nin hasta bakımının kritik parçası olduğunu ve olayın yüzlerce kuruma yayılabileceğini gösterir. S48 S54

Öncelikli savunma

• Klinik güvenlik sorumlusu ile siber olay komutasını aynı karar yapısında birleştirmek.
• EHR/laboratuvar/radyoloji için downtime formları, veri yeniden giriş kontrolü ve karşılıklı yardım.
• Tıbbi cihaz segmentasyonu ve üretici destek sonu planı.
• Acil hesap kullanımını sıkı alarm ve olay sonrası incelemeyle yönetmek.
• Hasta iletişimi ve veri ihlali bildirimi için önceden onaylı, damgalamayan metinler.

Üniversiteler

Neden hedef oluyorlar?

Üniversiteler açık akademik kültür, öğrenci/mezun/ziyaretçi döngüsü, araştırma ağı, uluslararası iş birliği ve heterojen cihaz parkını birlikte taşır. Fikrî mülkiyet, sağlık araştırması, öğrenci kimliği ve ödeme verisi bulunabilir. Fakülte özerkliği merkezi güvenlik standardını zorlaştırabilir.

RaaS baskısı nasıl oluşur?

• Kayıt, sınav veya bütçe döneminde kesinti zaman baskısı yaratır.
• Araştırma verisi yeniden üretilemeyebilir; yıllarca süren çalışma kaybolabilir.
• Kimlik federasyonu ve e-posta hesabı çok sayıda bulut hizmetine erişim verir.
• Açık ağ gereksinimi ile yönetim/finans/araştırma sistemlerinin sınırı karışabilir.

Öncelikli savunma

• Öğrenci, personel, araştırma ve yönetim kimliklerini risk düzeyine göre ayırmak.
• Araştırma verisi için proje başında kurtarma ve saklama planı istemek.
• Federasyon uygulamalarını, OAuth izinlerini ve eski mezun/konuk hesaplarını düzenli temizlemek.
• Merkezi yedek hizmetini laboratuvar ve fakültelere kolay erişilebilir sunmak.
• Sınav/kayıt dönemine özgü tabletop ve manuel hizmet planı yapmak.

Okullar ve eğitim bölgeleri

Neden hedef oluyorlar?

Okullar sınırlı BT personeli, çok sayıda paylaşılan cihaz, öğretmen/öğrenci hesabı, velilere açık portallar ve hızlı dönemsel kullanıcı değişimi nedeniyle zor savunulan ortamlardır. Çocuklara ait verinin hassasiyeti gasp baskısını artırır.

RaaS baskısı nasıl oluşur?

• Ders, yoklama, ulaşım ve yemek hizmeti sistemleri kesilebilir.
• Öğrenci ve veli iletişim bilgisi dolandırıcılıkta kullanılabilir.
• Eski hesap ve düşük maliyetli SaaS entegrasyonları kimlik alanını genişletir.
• Okul yönetimi kamu baskısı altında hızlı fakat kanıtsız açıklama yapmaya zorlanabilir.

Öncelikli savunma

• Yönetici ve personel için phishing-resistant MFA; öğrenci için yaşa/riske uygun doğrulama.
• Paylaşılan cihazları kişisel yönetici hesabından arındırmak ve merkezi yamalamak.
• Öğrenci bilgi sistemi ve ulaşım/yemek planı için çevrimdışı günlük çalışma çıktısı.
• Kullanıcı yaşam döngüsünü dönem kapanışında otomatik sonlandırmak.
• Çocuk verisi ihlalinde hukuki ve psikososyal iletişim planı hazırlamak.

Bankalar ve finans kuruluşları

Neden hedef oluyorlar?

Finans kurumları yüksek düzenleyici baskı, gerçek zamanlı hizmet beklentisi ve doğrudan para/veri değeri taşır. Genellikle güvenlik olgunlukları yüksektir; buna karşılık tedarikçi, çağrı merkezi, birleşme/devralma, üçüncü taraf dosya aktarımı ve ayrıcalıklı kullanıcı zinciri hedeflenebilir.

RaaS baskısı nasıl oluşur?

• Ödeme, mobil bankacılık veya işlem mutabakatı kesintisi hızlı ekonomik etki yaratır.
• Müşteri verisi ve iç denetim belgeleri düzenleyici/itibar baskısını büyütür.
• Dolandırıcılık olayı ile ransomware olayı eş zamanlı yürüyebilir; kaynaklar bölünür.
• Yüksek dayanıklılık nedeniyle saldırgan doğrudan kurum yerine kritik tedarikçiye yönelebilir.

Öncelikli savunma

• Ayrıcalıklı işlem, veri dışa aktarma ve yedek silmede ikili kontrol.
• Dolandırıcılık, SOC ve kimlik ekiplerinin ortak olay zaman çizelgesi.
• Ana sistem için alternatif merkez kadar kimlik, DNS, sertifika ve dış bağlantı kurtarması.
• Tedarikçide RTO/RPO, alt yüklenici, veri akışı ve olay bildirim testleri.
• Yönetici ve çağrı merkezi için kimlik geri kazanma sosyal mühendislik tatbikatı.

Enerji şirketleri

Neden hedef oluyorlar?

Enerji üretim, iletim ve dağıtımı fiziksel güvenlik ve kamu düzeniyle doğrudan ilişkilidir. BT, OT, planlama, ticaret, ölçüm, faturalama ve saha operasyonları birbirine bağımlıdır. OT doğrudan etkilenmese bile BT güveni kaybolduğunda güvenli işletme kararı verilemeyebilir; Colonial Pipeline bunu görünür kıldı. S40

RaaS baskısı nasıl oluşur?

• Hizmet kesintisi toplumsal ve siyasi baskı doğurur.
• Saha bakım, yakıt planlama veya faturalama kaybı operasyonu durdurabilir.
• Uzun ömürlü OT varlıkları ve vendor erişimi hızlı güncellemeyi zorlaştırır.
• İş ağı ile kontrol ağı arasındaki veri akışları yanlış güven alanı yaratabilir.

Öncelikli savunma

• BT–OT veri ve güven akışını tek tek belgelemek; güvenlik duvarı kuralını mimari kanıt saymamak.
• OT vendor erişimini süreli, izlenen, atlama sunuculu ve acil iptal edilebilir yapmak.
• Güvenli durdurma/ada çalışma ve manuel kontrol prosedürünü siber senaryoyla tatbik etmek.
• OT mühendislik yedeklerini çevrimdışı ve doğrulanmış tutmak.
• Güvenlik olayında fiziksel emniyet, operasyon ve siber ekibin ortak karar eşiğini belirlemek.

Lojistik ve taşımacılık firmaları

Neden hedef oluyorlar?

Lojistik; rota, depo, gümrük, filo, müşteri entegrasyonu, el terminali ve gerçek zamanlı veri akışına bağımlıdır. Dar teslimat pencereleri nedeniyle birkaç saatlik kesinti bile zincirleme gecikme yaratır.

RaaS baskısı nasıl oluşur?

• Sevkiyat ve stok görünürlüğü kaybolur.
• Gümrük ve taşıma belgeleri üretilemez.
• Müşteri EDI/API bağlantıları üçüncü taraf yayılma veya sahtecilik riski taşır.
• Depo otomasyonu dururken fiziksel mal akışı birikmeye devam eder.

Öncelikli savunma

• Kritik rota, araç, yük ve müşteri bilgisi için salt okunur acil görünüm.
• Depo/fabrika otomasyonu ile ofis/konuk/tedarikçi ağını ayırmak.
• EDI/API kimliklerini insan hesaplarından ayrı, en az yetkili ve döndürülen yapmak.
• Manuel sevk irsaliyesi ve sonradan mutabakat kontrolü hazırlamak.
• Tedarik zinciri boyunca siber kesinti bildirim formatı ve güvenli alternatif iletişim kanalı kurmak.

Üretim tesisleri

Neden hedef oluyorlar?

Üretim, kesinti maliyeti ve zaman baskısı yüksek; tesis başına özel sistemleri olan bir sektördür. Merkezi ERP, reçete, kalite, bakım ve etiketleme sistemleri fiziksel hattın çalışması için gerekli olabilir. Güvenlik yaması üretim duruşu gerektirdiğinde ertelenebilir.

RaaS baskısı nasıl oluşur?

• Hat duruşu, hurda, kalite ve teslimat cezası doğurur.
• Fikrî mülkiyet ve müşteri sözleşmesi veri gaspını güçlendirir.
• Eski mühendislik iş istasyonu veya ortak vendor hesabı yayılma yolu olabilir.
• Yedek var olsa da makine konfigürasyonu, lisans ve kalibrasyon toparlanmayı uzatır.

Öncelikli savunma

• Ürün/hat bazında maksimum kabul edilebilir kesinti ve manuel üretim sınırı.
• OT varlık, firmware, reçete ve mühendislik dosyası için doğrulanmış çevrimdışı kopya.
• Bakım laptopu, taşınabilir ortam ve vendor erişimi için karantina/izin süreci.
• Hat güvenliği ve ürün kalitesi doğrulanmadan üretimi yeniden başlatmamak.
• Yama penceresini risk kabulüyle değil telafi edici kontrol ve belirli son tarihle yönetmek.

Sektörlerden bağımsız ortak zayıflıklar

RaaS açısından neden önemli?

RaaS hedef seçimi sektör isminden çok kesinti, veri, erişim ve kurtarma baskısına dayanır. Bu bölüm, sekiz kurum türünde aynı ekonomik modelin neden farklı operasyonel sonuçlar doğurduğunu ve savunmanın sektörün gerçek hizmet bağımlılığına nasıl uyarlanacağını gösterir.

Erken Uyarı İşaretleri

Neden erken uyarı şifreleme alarmından değerlidir?

Şifreleme alarmı gerekli ama çoğu zaman geçtir. RaaS zincirinde kimlik anormalliği, ayrıcalık değişimi, yönetim düzlemine erişim, veri toplama ve yedek kurcalama daha erken görünür. Etkili erken uyarı tek bir “kesin RaaS imzası” aramaz; düşük güvenli sinyalleri iş ve kimlik bağlamıyla birleştirir.

Tespit ilkesi: Bir işaret tek başına saldırı kanıtı olmayabilir. Fakat yeni cihaz + MFA sıfırlama + ayrıcalıklı rol + yedek konsol erişimi gibi zincir, her bir alarmın toplamından daha güçlüdür.

Kullanıcıların görebileceği belirtiler

Kimlik ve iletişim belirtileri

• Kullanıcının başlatmadığı MFA bildirimi, parola sıfırlama veya cihaz kaydı.
• Yardım masası/BT görevlisi gibi davranan kişinin aceleyle kod, onay veya yazılım istemesi.
• Gelen kutusunda bilinmeyen yönlendirme kuralı, silinen güvenlik bildirimi veya “okunmuş” mesaj.
• Hesabın kilitlenmesi ya da normal uygulamalarda beklenmeyen yeniden oturum açma.
• Çok sayıda abonelik/istenmeyen e-postanın gerçek güvenlik uyarısını saklaması.

Cihaz ve dosya belirtileri

• Kullanıcının kurmadığı uzak destek/yönetim yazılımı.
• Dosyaların açılmaması, adlarının toplu değişmesi veya paylaşımlarda aniden hata oluşması.
• Güvenlik yazılımının kapalı görünmesi ya da “kuruluşunuz yönetti” ilkesinin beklenmedik değişmesi.
• Cihazın açıklanamayan biçimde yavaşlaması; ağ diski veya dosya sunucusunda yoğun işlem.
• Masaüstünde fidye notu veya kurum dışı iletişim talebi.

Kullanıcı ne yapmalı?

Kullanıcı cihazı kendi başına “temizlemeye”, fidye notuna yanıt vermeye veya dosyaları silmeye çalışmamalıdır. Kurumun tanımlı kanalından olayı bildirmeli; şüpheli oturum/MFA bildirimini reddetmeli; olay prosedürü söylüyorsa ağı kesmeli ama cihazı kapatmanın uçucu delil üzerindeki etkisini olay ekibine bırakmalıdır. Ev kullanıcısı ise cihazın internet bağlantısını ayırıp güvenilir başka cihazdan hesap oturumlarını iptal etmeli ve profesyonel destek almalıdır.

Sistem yöneticilerinin görebileceği belirtiler

Kimlik ve ayrıcalık

• Yeni yönetici hesabı, beklenmeyen grup üyeliği veya rol ataması.
• Servis hesabının etkileşimli oturum açması.
• Eski/ayrılmış çalışan hesabının yeniden etkinleşmesi.
• MFA yöntemi ekleme/silme ve hemen ardından yönetim işlemi.
• Aynı kimliğin kullanıcı, sunucu, yedek ve bulut yönetimine kısa aralıkta erişmesi.

Yönetim ve güvenlik düzlemi

• EDR politikasının kapatılması, ajan kaldırılması veya kurcalama koruması alarmı.
• Günlük kaynağının susması, saklama süresinin düşürülmesi veya saat senkronizasyon bozulması.
• Yedek saklama politikasının değiştirilmesi, toplu silme veya geri yükleme noktasının kaybolması.
• Hipervizör, RMM, dizin veya bulut konsolunda alışılmadık toplu işlem.
• Yeni uzak yönetim aracı veya script dağıtım işi.

Dosya ve veri davranışı

• Dosya sunucusunda sıra dışı sayıda okuma, yeniden adlandırma ve yazma.
• Kısa sürede büyük arşiv/geçici dosya oluşumu.
• Veri tabanı veya belge yönetiminden alışılmadık toplu dışa aktarma.
• İş birimiyle uyuşmayan hassas veri erişimi.

Ağ üzerindeki belirtiler

• Yeni veya nadir dış hedefe uzun süreli/yüksek hacimli veri çıkışı.
• Kullanıcı segmentinden yönetim, yedek veya hipervizör segmentine erişim denemesi.
• Bir uç noktadan çok sayıda iç sisteme kimlik doğrulama veya bağlantı.
• Normal bakım penceresi dışında yönetim protokolü trafiği.
• DNS sorgularında yeni, seyrek, otomatik üretilmiş veya kısa ömürlü hedef örüntüsü.
• Bulut depolama/iş birliği hizmetine kullanıcı taban çizgisini aşan yükleme.
• Güvenlik kontrolü tarafından engellenince farklı çıkış yoluna tekrarlayan deneme.

IP adresi veya ülke tek başına karar vermek için zayıftır. Meşru bulut ve ele geçirilmiş altyapı kötüye kullanılabilir. Kimlik, cihaz, hedef, veri hacmi ve iş gerekçesi birlikte değerlendirilmelidir.

Log kayıtlarındaki belirtiler

Kimlik günlükleri

• Başarılı oturumun hemen öncesinde yoğun başarısız deneme veya MFA reddi.
• Yeni cihaz kaydı, riskli oturum, token yenileme ve rol değişikliğinin zincir hâlinde görülmesi.
• “Impossible travel” benzeri uyarı; ancak VPN ve mobil ağ kaynaklı yanlış pozitifler doğrulanmalıdır.
• Eski protokol veya koşullu erişim istisnasından oturum.
• Yardım masası biletinde MFA sıfırlama ile SIEM'de yeni coğrafya/cihaz ilişkisinin bulunması.

İşletim sistemi ve dizin günlükleri

• Yeni hizmet/görev, yeni yerel kullanıcı veya yönetici grubu değişikliği.
• Çok sayıda sistemde aynı hesapla eş zamanlı yönetim oturumu.
• Güvenlik günlüğü temizleme, denetim ilkesi değişikliği veya ajan durdurma.
• Kimlik bilgisi, dizin veya ağ keşfine işaret eden olağandışı davranış kümeleri.
• Dosya paylaşımında toplu erişim ve başarısız izin denemeleri.

Bulut ve SaaS günlükleri

• Yeni uygulama kaydı, OAuth izni, API anahtarı veya erişim politikası değişikliği.
• Toplu indirme, dış paylaşım ve yeni kişisel depoya aktarım.
• Yedek/retention/saklama kilidinin kaldırılması girişimi.
• Yönetici rolünün kısa süreli atanıp geri alınması.
• Kullanıcı hesabından posta yönlendirme veya gizli gelen kutusu kuralı.

Ağ, DNS ve proxy günlükleri

• Nadir hedef, yeni kayıtlı alan veya olağandışı kullanıcı aracısı tek başına değil bağlamla incelenir.
• Yüksek veri çıkışı ile hassas dosya erişiminin zaman korelasyonu.
• Engellenen hedef sonrası izinli bulut hizmetine yönelme.
• İç yönetim trafiğinin beklenmeyen kaynak segmentten gelmesi.

CISA, günlüklerin merkezî tutulmasını ve güvenlik olaylarını araştırabilecek yeterli ayrıntı/süreyle korunmasını önerir. SIEM/SOAR rehberi, veri kaynağı kalitesinin otomasyondan önce geldiğini vurgular. S18

EDR uyarıları

EDR, RaaS'ın son şifreleyicisini yakalamanın ötesinde şu davranış kümelerinde değerlidir:

• Güvenlik aracını kapatma veya kurcalama girişimi.
• Kullanıcı cihazında beklenmeyen yönetim aracı veya uzaktan çalıştırma davranışı.
• Ofis/iletişim uygulamasından alışılmadık süreç zinciri.
• Kimlik bilgisi ve dizin keşfiyle uyumlu şüpheli bellek/işlem davranışı.
• Çok sayıda dosyada hızlı değişiklik ya da paylaşımlara toplu erişim.
• Yedek, kurtarma veya gölge kopya ayarına müdahale.
• Yeni servis, görev, otomatik başlatma veya yaygın dağıtım davranışı.

EDR alarmı “kapat ve unut” değildir. Bir cihazı otomatik izole etmek iş güvenliği açısından doğru olabilir; ancak sağlık/üretim ortamında yanlış pozitif zararını azaltmak için cihaz sınıfı, kritik süreç ve manuel geri alma yolu önceden belirlenmelidir.

RaaS'a özgü korelasyon örnekleri

Erken uyarı işaretlerinde yanlış pozitif yönetimi

Yanlış pozitif korkusuyla alarmı susturmak, RaaS için erken müdahale penceresini kapatır. Her alarm için:

1. Beklenen meşru iş örneklerini tanımlayın.
2. Varlık kritiklik, kullanıcı rolü ve değişiklik biletiyle zenginleştirin.
3. Otomatik engelleme ile yalnızca uyarı arasındaki eşiği test edin.
4. Yanlış pozitif nedenini kural iyileştirmesine dönüştürün; alarmı tamamen kapatmayın.
5. “Bir daha olmaz” istisnasına son tarih ve sahibi atayın.

Minimum log kaynakları ve saklama hedefi

• Kimlik sağlayıcı/SSO/MFA: oturum, risk, cihaz, yöntem değişikliği, rol.
• Dizin ve ayrıcalık: grup/rol, hesap, servis hesabı, kasa erişimi.
• Uç nokta/EDR: süreç, ağ, dosya, ajan durumu ve izolasyon.
• DNS/proxy/güvenlik duvarı: ad çözümleme, çıkış, iç segment akışı.
• E-posta/iş birliği: kural, yönlendirme, uygulama izni, paylaşım.
• Bulut kontrol düzlemi: rol, anahtar, politika, saklama ve toplu işlem.
• Yedek/sanallaştırma/RMM: oturum, iş, silme, politika ve geri yükleme.
• Kritik uygulama/veri: toplu okuma, dışa aktarma, erişim reddi ve yönetim işlemi.

Saklama süresi tek bir sayı değildir; IAB erişimi ile şifreleme arasında haftalar/aylar olabileceği için kurum, tehdit modeli ve düzenleyici gereksinime göre sıcak arama ile arşiv süresini ayırmalıdır. Günlüklerin saldırganın aynı yönetim alanından silemeyeceği bağımsız hedefe akması önemlidir.

Kullanıcı, SOC ve yönetim için eşik

RaaS açısından neden önemli?

RaaS etkisi şifreleme anından önce kimlik, ayrıcalık, yönetim düzlemi ve veri hareketinde iz bırakır. Bu bölüm kullanıcıdan EDR'ye kadar işaretleri aynı zincirde birleştirir; böylece kurum fidye notunu beklemeden saldırganın ekonomik modelini bozabilecek erken müdahale penceresi kazanır.

RaaS'a Karşı Savunma

Savunma stratejisinin mimarisi

RaaS'a karşı tek bir ürün veya “gümüş kurşun” yoktur. Etkili program, saldırganın ekonomik zincirini birden fazla noktada kırar:

NIST IR 8374 Rev. 1, ransomware riskini CSF 2.0'ın Govern, Identify, Protect, Detect, Respond ve Recover işlevlerine bağlar. Bu, savunmanın yalnızca “Protect” ürünü olmadığını; yönetim, hazırlık, müdahale ve toparlanma sorumluluğu olduğunu gösterir. S03 S04

Kontrol 1 – MFA (Çok Faktörlü Kimlik Doğrulama)

Nedir?

MFA, bir oturum veya hassas işlem için birbirinden bağımsız en az iki kanıt ister: bilinen sır, sahip olunan cihaz/anahtar veya biyometrik kanıt. RaaS bağlamında en güçlü seçenek, sahte oturum açma sayfasına kod teslim etmeyen ve gerçek hizmet alanına kriptografik olarak bağlanan FIDO/WebAuthn türü phishing-resistant MFA'dır. S17

Neden gereklidir?

Parola; yeniden kullanım, bilgi hırsızı, veri sızıntısı, sosyal mühendislik veya tedarikçi ihlaliyle ele geçirilebilir. IAB ekonomisi çalışır kimlik bilgisini ticari mala dönüştürür. MFA, parolanın tek başına oturuma dönüşmesini önler ve ele geçirilmiş erişimin satış değerini düşürür.

RaaS'a karşı nasıl korur?

• E-posta, VPN, SSO, bulut ve yönetim konsolunda çalınmış parolayı durdurur.
• Ayrıcalıklı hesapta ikinci faktör ve cihaz bağı, yönetim düzlemine sıçramayı zorlaştırır.
• Hassas işlemlerde adım yükseltmeli doğrulama; yedek silme, rol atama ve anahtar oluşturmayı korur.
• Yardım masası sıfırlama süreciyle birlikte uygulandığında sosyal mühendislik zincirini kırar.

Tek başına yeterli mi?

Hayır. SMS ve tek kullanımlık kodlar kimlik avı veya SIM saldırısına açık olabilir. MFA yorgunluğu, yardım masası üzerinden faktör sıfırlama, oturum belirteci hırsızlığı, eski protokol ve kayıtlı kötü niyetli cihaz MFA'yı aşabilir. MFA; cihaz güveni, oturum analitiği, eski kimlik doğrulamayı kapatma ve yardım masası kontrolüyle tamamlanmalıdır.

Kurumlarda nasıl uygulanır?

1. Tüm oturum yollarını çıkarın: web, mobil, VPN, e-posta, eski protokol, API, servis hesabı, tedarikçi ve acil hesap.
2. Önce ayrıcalıklı, uzaktan ve kritik hesaplarda FIDO2/passkey veya sertifika tabanlı phishing-resistant MFA uygulayın.
3. Kullanıcıları MFA'ya almakla yetinmeyin; MFA'sız eski protokol ve uygulama parolalarını kapatın.
4. Yeni faktör kaydı ve sıfırlamayı güçlü kimlik kanıtı, gecikme/ikinci onay ve bağımsız alarm ile koruyun.
5. Acil hesabı çevrimdışı saklanan kimlik bilgisi, fiziksel/ikili erişim ve her kullanımda kritik alarm ile yönetin.
6. Ölçün: MFA kapsamı değil MFA'sız başarılı oturum sayısı, phishing-resistant oranı, sıfırlama sayısı ve istisna yaşı.

Ev kullanıcıları nasıl uygulayabilir?

Önce e-posta, parola yöneticisi, banka, bulut depolama ve sosyal medya hesaplarında passkey veya fiziksel güvenlik anahtarı kullanın. Bu yoksa doğrulama uygulaması, SMS'ten daha iyi tercihtir. Kurtarma kodlarını çevrimdışı saklayın; başlatmadığınız onayı reddedin; bir “destek görevlisine” kod söylemeyin. Hesap ayarlarında tanımadığınız cihaz ve oturumları düzenli kapatın.

Kontrol 2 – Zero Trust

Nedir?

Zero Trust, ağ konumuna veya geçmiş oturuma kalıcı güven vermeyen; her kaynak erişimini kimlik, cihaz, bağlam, risk ve en az yetkiyle değerlendiren mimari yaklaşımdır. Bir ürün adı değildir. NIST SP 800-207 kaynağı merkeze alır; SP 1800-35 uygulanabilir örnek mimarileri açıklar. S06 S07

Neden gereklidir?

Geleneksel “iç ağ güvenlidir” varsayımı, ilk erişimden sonra saldırgana geniş hareket alanı verir. Bulut, uzaktan çalışma, SaaS ve tedarikçi erişimi ağ çevresini belirsizleştirmiştir. RaaS bağlı kuruluşu meşru hesap kullandığında basit IP tabanlı güven yetersizdir.

RaaS'a karşı nasıl korur?

• Ele geçirilmiş hesabın yalnızca açıkça yetkili olduğu kaynaklara ulaşmasını sağlar.
• Yeni cihaz, yüksek riskli oturum veya hassas işlemde yeniden doğrulama ister.
• Yönetim, yedek ve sanallaştırma düzlemini kullanıcı ağından ayırır.
• Politika ve telemetriyi birleştirerek kimlik + cihaz + veri sinyalini erken müdahaleye dönüştürür.

Tek başına yeterli mi?

Hayır. Zero Trust etiketi kötü envanter, aşırı yetki veya test edilmemiş kurtarmayı düzeltmez. Yanlış politika hizmet kesintisi yaratabilir; kimlik sağlayıcının kendisi ele geçirilirse risk merkezileşir. Güçlü kimlik, cihaz yönetimi, segmentasyon, günlükleme ve yedekleme gerekir.

Kurumlarda nasıl uygulanır?

1. “Zero Trust satın alma” yerine kritik hizmet ve veri akışını seçin.
2. Kimlik, cihaz, uygulama ve veri envanterini sahipleriyle eşleştirin.
3. En riskli yol olan kullanıcı → yönetim/yedek/hipervizör erişimini kapatın.
4. Koşullu erişimde cihaz sağlığı, kimlik riski, konum, davranış ve veri sınıfını kullanın.
5. Hizmet hesapları ve makine kimlikleri için kısa ömürlü kimlik bilgisi ve iş yükü kimliği uygulayın.
6. Politika değişikliğini kod/değişiklik yönetimi, test ve geri alma ile yönetin.
7. Ölçün: varsayılan izinli akış, kalıcı ayrıcalık, yönetilmeyen cihaz erişimi ve politika istisnası sayısı.

Ev kullanıcıları nasıl uygulayabilir?

Evde “Zero Trust ürünü” gerekmez. Karşılığı; her hesapta benzersiz kimlik, cihaz kilidi/şifreleme, yönetici hesabını günlük kullanmama, IoT cihazlarını misafir ağına ayırma ve bilinmeyen uygulamaya geniş bulut izni vermemektir. Aile bireyleri ayrı hesap kullanmalı; ana e-posta hesabı diğer hesapların kurtarma anahtarı olduğu için en güçlü şekilde korunmalıdır.

Kontrol 3 – PAM (Ayrıcalıklı Erişim Yönetimi)

Nedir?

PAM; yönetici, kök, servis, yedek, hipervizör, bulut ve güvenlik konsolu erişimini kasaya alma, döndürme, tam zamanında verme, oturumu izleme ve yüksek riskli işlemi onaya bağlama disiplinidir.

Neden gereklidir?

RaaS etkisi, saldırganın sıradan hesaptan yönetim düzlemine geçmesiyle büyür. Kalıcı domain admin, ortak root hesabı, yıllarca değişmeyen servis parolası veya üretim dizinine bağlı yedek yöneticisi tek hata alanıdır.

RaaS'a karşı nasıl korur?

• Kalıcı ve paylaşılmış ayrıcalığı azaltarak kimlik hırsızlığının yarıçapını daraltır.
• Yedek silme, EDR kapatma ve rol atama gibi işlemlere ikinci onay sağlar.
• Ayrıcalıklı oturum kaydı ve komut/işlem bağlamı adli görünürlük verir.
• Sırları otomatik döndürerek eski erişimin yeniden kullanılmasını zorlaştırır.

Tek başına yeterli mi?

Hayır. PAM yanlış yapılandırılırsa veya aynı dizin/backup alanına bağlıysa yüksek değerli tek hedef olur. Her servisi kasaya almak ama yetkiyi azaltmamak yalnızca merkezi parola depolar. PAM; segmentasyon, MFA, JIT, güvenli yönetim iş istasyonu ve acil hesap yönetişimiyle birlikte çalışmalıdır.

Kurumlarda nasıl uygulanır?

1. Önce Tier-0: kimlik, yedek, hipervizör, bulut, ağ ve güvenlik yönetimi hesaplarını envantere alın.
2. Kişiye özgü yönetici hesabı kullanın; ortak hesap kullanımını onaylı ve izlenen istisnaya dönüştürün.
3. Kalıcı üyelik yerine istek–onay–süreli yetki ve otomatik geri alma uygulayın.
4. Servis hesaplarının etkileşimli oturumunu kapatın; sırlarını uygulama kesintisi testiyle döndürün.
5. PAM altyapısını ayrı yönetim segmenti, phishing-resistant MFA ve değiştirilemez günlükle koruyun.
6. “Break-glass” hesabını çevrimdışı, çift kişi kontrollü tutun ve düzenli kontrollü test edin.
7. Ölçün: kalıcı admin sayısı, paylaşılan hesap, döndürülmeyen sır yaşı, onaysız oturum ve yetki süresi.

Ev kullanıcıları nasıl uygulayabilir?

Ev kullanıcısında PAM ürünü gerekmez. Günlük işler için standart kullanıcı hesabı, kurulum için ayrı yönetici hesabı kullanın. Parolaları güvenilir parola yöneticisinde benzersiz saklayın; modem/NAS yönetici parolasını varsayılandan değiştirin; yönetim panelini internete açmayın. Aile içinde aynı yönetici parolasını paylaşmayın.

Kontrol 4 – EDR (Endpoint Detection and Response)

Nedir?

EDR; uç nokta ve sunucularda süreç, dosya, kimlik, ağ ve güvenlik durumu telemetrisi toplayan; davranış analizi, araştırma, izolasyon ve müdahale sağlayan teknolojidir. Antivirüsten daha geniş görünürlük sunar.

Neden gereklidir?

RaaS bağlı kuruluşları meşru araçları kötüye kullanabilir, her olay için farklı örnek üretebilir ve imza tabanlı algılamadan kaçınabilir. Play uyarısı, her saldırı için yeniden derlenen örneklerin hash tespitini zorlaştırdığını belirtir. S34

RaaS'a karşı nasıl korur?

• Güvenlik aracı kurcalama, uzak yönetim, ayrıcalık, veri toplama ve toplu dosya değişimini davranış olarak görür.
• Şüpheli cihazı ağdan izole ederek yayılma ve şifrelemeyi sınırlar.
• Olay zaman çizelgesi ve süreç ağacı adli kapsam belirlemeyi hızlandırır.
• Tehdit avcılığı için geriye dönük sorgulanabilir telemetri sağlar.

Tek başına yeterli mi?

Hayır. Ajanın kurulmadığı/çalışmadığı varlık kör noktadır. Bulut kontrol düzlemi, ağ cihazı, SaaS ve kimlik olayı yalnızca EDR'de görünmeyebilir. Ayrıcalıklı saldırgan ajanı kapatmaya çalışabilir. EDR; tam kapsama, kurcalama koruması, SIEM/XDR, ağ/kimlik günlükleri ve insan analizi gerektirir.

Kurumlarda nasıl uygulanır?

1. Uç nokta kadar sunucu, VDI, yönetim iş istasyonu ve desteklenen bulut iş yüklerini kapsayın.
2. Kurcalama korumasını açın; kapatma/ajan kaybını bağımsız SIEM ve yönetim kanalına iletin.
3. Yüksek güvenli ransomware davranışında izolasyon politikasını cihaz kritikliğine göre test edin.
4. RMM ve yönetim araçları için geniş allowlist yerine imza, yol, kullanıcı, zaman ve hedef bağlamı kullanın.
5. Telemetri saklama süresini IAB erişimi ile etki arasındaki gecikmeyi araştırabilecek biçimde planlayın.
6. Kör nokta ölçün: EDR'siz, sağlıksız, eski sürüm, politika dışı ve son 24 saatte veri göndermeyen cihaz oranı.

Ev kullanıcıları nasıl uygulayabilir?

Güncel işletim sisteminin yerleşik korumasını, gerçek zamanlı tarama ve bulut tabanlı korumayı açık tutun. Güvenlik yazılımını “performans için” kapatmayın. İşletim sistemi ve tarayıcıyı otomatik güncelleyin. Birden çok antivirüsü birlikte çalıştırmak korumayı artırmayabilir; çakışma yaratabilir. Şüpheli dosyayı test etmek için kişisel ana cihazı kullanmayın.

Kontrol 5 – XDR (Extended Detection and Response)

Nedir?

XDR; uç nokta, kimlik, e-posta, ağ, bulut ve SaaS sinyallerini ortak olay bağlamında birleştirerek tespit ve müdahaleyi genişleten yaklaşımdır. Tek üretici platformu veya iyi entegre edilmiş çoklu araç seti olabilir; önemli olan veri ve karar bütünlüğüdür.

Neden gereklidir?

RaaS zinciri tek katmanda kalmaz. MFA sıfırlama kimlikte, şüpheli ek e-postada, uzak araç uç noktada, veri çıkışı ağda ve yedek silme bulut kontrol düzleminde görünebilir. Bu sinyaller ayrı kuyruklarda kalırsa ilişki geç kurulur.

RaaS'a karşı nasıl korur?

• Kimlik + cihaz + e-posta + veri hareketini tek olayda korele eder.
• Saldırganın “meşru hesap ve meşru araç” kullanımını bağlamdan anormal bulur.
• Oturumu iptal etme, cihazı izole etme ve e-postayı geri çekme gibi çok alanlı müdahaleyi hızlandırır.
• SOC'un onlarca düşük seviyeli alarm yerine aşama zincirini görmesini sağlar.

Tek başına yeterli mi?

Hayır. XDR kötü kaynak verisini düzeltemez; entegrasyon kapsamı pazarlama sayfasından farklı olabilir. Otomatik korelasyon yanlış bağ kurabilir. Tedarikçi bağımlılığı ve telemetri taşınabilirliği de değerlendirilmelidir.

Kurumlarda nasıl uygulanır?

1. Önce RaaS senaryolarını seçin: MFA sıfırlama → yeni cihaz → rol → yedek erişimi gibi.
2. Her senaryo için gerekli veri kaynağı, alan, zaman senkronu ve saklama süresini doğrulayın.
3. XDR'nin gördüğü varlık/kimlik kapsamını CMDB ve kimlik envanteriyle karşılaştırın.
4. Otomatik müdahaleyi önce gölge modda, sonra düşük riskli varlıkta, son olarak kritik sistemde kontrollü devreye alın.
5. Ürün dışına olay/telemetri aktarımı ve çıkış planı belirleyin.
6. Ölçün: çok alanlı olay başına araştırma süresi, korelasyon doğruluğu ve kapsanmayan kaynak sayısı.

Ev kullanıcıları nasıl uygulayabilir?

Ev için XDR ürünü genellikle gereksizdir. Karşılığı, ana e-posta hesabının güvenlik panelini, cihaz listelerini ve bulut depolama uyarılarını düzenli kontrol etmek; aile cihazlarında aynı güvenilir platformun güncel korumasını kullanmak ve kritik hesaplarda oturum bildirimlerini açmaktır.

Kontrol 6 – SIEM (Security Information and Event Management)

Nedir?

SIEM; farklı sistemlerden güvenlik günlüklerini merkezî toplar, normalize eder, ilişkilendirir, aratır ve alarm üretir. RaaS açısından temel değeri, ilk erişim ile şifreleme arasında dağılmış zaman çizelgesini birleştirmektir.

Neden gereklidir?

Yerel günlük saldırgan tarafından silinebilir; ayrı ekipler aynı hesabın farklı sistemlerdeki davranışını göremeyebilir. Günler/haftalar önceki erişim, olay anında geriye dönük sorgu gerektirir. CISA'nın SIEM/SOAR rehberi, iyi planlanmış günlük kaynakları ve uygulama mimarisini vurgular. S18

RaaS'a karşı nasıl korur?

• Kimlik, EDR, yedek, hipervizör, bulut ve ağ olaylarını ilişkilendirir.
• Ayrıcalık, veri çıkışı ve yedek kurcalama zincirini erken alarm hâline getirir.
• Yerel sistem kaybında adli araştırma için bağımsız kayıt sağlar.
• Olay sonrası kapsam, bildirim ve ders çıkarma için kanıt üretir.

Tek başına yeterli mi?

Hayır. “Her logu toplamak” görünürlük değil gürültü ve maliyet yaratabilir. Eksik alan, yanlış saat, kısa saklama veya alarm sahibinin olmaması SIEM'i etkisiz kılar. SIEM olay engellemez; tespit ve karar kalitesi insan/süreç gerektirir.

Kurumlarda nasıl uygulanır?

1. Kritik RaaS sorularından başlayın: Bu hesabın MFA'sı kim sıfırladı? Hangi yedek silindi? Veri nereye çıktı?
2. Kimlik, ayrıcalık, EDR, DNS/proxy, bulut, e-posta, yedek, hipervizör ve kritik uygulama günlüklerini önceliklendirin.
3. Alan kalitesi, zaman senkronu, kaynak kaybı ve günlük gecikmesi için sağlık alarmı kurun.
4. Her korelasyon kuralına sahip, önem, ilk eylem ve yanlış pozitif geri bildirim süreci atayın.
5. Günlüğü saldırganın aynı yetkiyle silemeyeceği ayrı hesaba/depoya gönderin.
6. Ölçün: günlük kaynağı kapsama oranı değil, kritik soruyu yanıtlama süresi, kaynak kaybı ve işe yarayan alarm oranı.

Ev kullanıcıları nasıl uygulayabilir?

Evde SIEM kurulması genellikle gereksiz ve yönetilemezdir. İşletim sistemi güvenlik geçmişi, yönlendirici bağlı cihaz listesi, e-posta oturum geçmişi ve bulut hesap güvenlik günlüklerini gerektiğinde kontrol edin. Kritik bir olayda günlükleri silmek yerine cihazı ayırıp profesyonel destek için koruyun.

Kontrol 7 – SOAR (Security Orchestration, Automation and Response)

Nedir?

SOAR; güvenlik araçları ve iş akışları arasında otomasyon kurarak zenginleştirme, biletleme, onay, izolasyon, oturum iptali ve iletişim gibi adımları tutarlı biçimde yürütür.

Neden gereklidir?

RaaS operasyonunda dakikalar önemlidir. İnsan analistin aynı bilgiyi beş konsolda araması veya her hesabı elle kapatması saldırganın yayılma süresini artırır. Standardize edilmiş playbook karar gecikmesini düşürür.

RaaS'a karşı nasıl korur?

• Riskli kimlik olayında oturumları iptal eder, cihazı işaretler ve yardım masası kaydını ilişkilendirir.
• EDR kurcalama + yedek değişikliği gibi kritik korelasyonda olay komutasını otomatik çağırır.
• Bilinen kötü göstergeleri tüm katmanlarda arar ve kapsam listesini hızla çıkarır.
• Delil toplama ve karar günlüğünü tekrarlanabilir hâle getirir.

Tek başına yeterli mi?

Hayır. Kötü tasarlanmış otomasyon büyük iş kesintisi yaratabilir; saldırgan otomasyon hesabını hedefleyebilir. SOAR, insan muhakemesi ve yetki sınırının yerini almaz. “Her kritik alarmda tüm ağı kapat” güvenli playbook değildir.

Kurumlarda nasıl uygulanır?

1. Önce düşük riskli zenginleştirme/biletleme, sonra geri alınabilir müdahale, en son yüksek etkili izolasyon otomasyonu.
2. Her playbook için tetik, veri güveni, insan onayı, azami etki alanı, geri alma ve durdurma düğmesi tanımlayın.
3. SOAR servis hesabına en az yetki ve kısa ömürlü kimlik bilgisi verin; tüm eylemleri değiştirilemez kayda alın.
4. Kritik hizmetleri kapsayan otomasyonları bakım dışı saatte ve masa başı tatbikatta test edin.
5. Üçüncü taraf/API kesintisinde manuel fallback hazırlayın.
6. Ölçün: ortalama kontrol altına alma süresi, başarısız/geri alınan otomasyon ve gereksiz izolasyon oranı.

Ev kullanıcıları nasıl uygulayabilir?

Evde SOAR gerekmez. İşletim sistemi ve hesap sağlayıcısının “şüpheli oturumda hesabı kilitle”, “cihazımı bul/uzaktan kilitle”, otomatik güncelleme ve bulut yedekleme gibi güvenilir otomasyonlarını açın. Bilinmeyen “tek tıkla güvenlik/temizleme” araçlarına yönetici yetkisi vermeyin.

Kontrol 8 – Immutable Backup (Değiştirilemez Yedek)

Nedir?

Değiştirilemez yedek, belirlenen saklama süresi boyunca yönetici dâhil hiç kimsenin kopyayı değiştiremediği veya silemediği WORM/object-lock benzeri korumadır. Gerçek dayanıklılık; teknik kilit, ayrı kimlik alanı, saklama politikası ve geri yükleme testi birlikte olduğunda oluşur. S08

Neden gereklidir?

RaaS bağlı kuruluşu, ödeme baskısını artırmak için üretimden önce yedek ve anlık görüntüleri hedefleyebilir. Yedek aynı dizin hesabı, aynı ağ ve aynı yönetim konsoluyla korunuyorsa üretim kadar erişilebilir olabilir.

RaaS'a karşı nasıl korur?

• Yedek silme veya saklama süresini kısaltma girişimini teknik olarak sınırlar.
• Saldırganın uzun süre bekleyip yedek döngüsünü “zehirleme” etkisini saklama/versiyonla azaltır.
• Fidye talebine karşı doğrulanmış kurtarma seçeneği sağlar.
• Yedek yönetim olaylarını erken uyarı sinyaline dönüştürür.

Tek başına yeterli mi?

Hayır. Değiştirilemez kopya zaten şifreli/bozuk veriyi saklayabilir; uygulama bağımlılıkları veya kimlik düzlemi yoksa işe yaramaz. Veri sızıntısını önlemez. Yanlış saklama, maliyet veya kilit süresi operasyonel sorun yaratabilir.

Kurumlarda nasıl uygulanır?

1. Kritik hizmet için RPO/RTO ve saklama penceresini iş etki analiziyle belirleyin.
2. Yedek hesabını üretim dizininden ve bulut aboneliğinden mümkünse ayırın.
3. Silme/retention değişikliği için phishing-resistant MFA, iki kişi onayı ve bağımsız alarm uygulayın.
4. Yedek katalog, anahtar, yapılandırma ve geri yükleme yazılımını da koruyun.
5. Temiz oda geri yüklemesi yapın; kötü amaçlı kalıcılık ve eski zafiyeti geri taşımayın.
6. Ölçün: başarılı iş sayısı değil başarılı geri yükleme, doğrulanmış veri bütünlüğü, gerçek RTO/RPO ve ayrı kimlikli kopya oranı.

Ev kullanıcıları nasıl uygulayabilir?

Sürekli bağlı tek USB disk değiştirilemez yedek değildir. Bir harici diski yalnızca yedek sırasında bağlayıp sonra ayırın; bulut sağlayıcısında sürüm geçmişi/çöp kutusu/saklama özelliklerini açın. Fotoğraf ve belgelerin en az bir kopyasını ayrı hesap veya fiziksel konumda tutun. Düzenli olarak birkaç dosyayı geri yükleyip açın.

Kontrol 9 – 3-2-1 Yedekleme

Nedir?

3-2-1 kuralı, verinin en az üç kopyasını, iki farklı ortamda ve bir kopyayı tesis/ana sistem dışında tutmayı hedefler. Modern uygulamada buna bir çevrimdışı/değiştirilemez kopya ve sıfır doğrulama hatası hedefi eklenerek “3-2-1-1-0” ifadesi de kullanılır.

Neden gereklidir?

Tek yedek; donanım arızası, kullanıcı hatası, yangın, hesap ele geçirme veya RaaS operasyonuyla aynı anda kaybedilebilir. Farklı hata alanları, tek kimlik ve tek sağlayıcı riskini azaltır.

RaaS'a karşı nasıl korur?

• Üretim ve çevrimiçi yedek şifrelense bile ayrı kopya kurtarma yolu sağlar.
• Bulut hesap ihlali veya tesis kaybında alternatif verir.
• Farklı zaman/saklama kopyaları, saldırganın uzun süreli sessiz kalıcılığına karşı geçmişe dönüş sağlar.
• Kurtarma seçeneği, fidye baskısını azaltır.

Tek başına yeterli mi?

Hayır. Kopya sayısı kaliteyi garanti etmez. Aynı bozuk veri üç yere kopyalanabilir; şifreleme anahtarı kaybolabilir; uygulama sırası bilinmeyebilir. Veri sızıntısı ve operasyonel bağımlılık sorununu çözmez.

Kurumlarda nasıl uygulanır?

1. Kopyaları aynı dizin, aynı bulut hesabı ve aynı yönetici kimliğinden ayırın.
2. Kritik veri yanında kimlik, sertifika, DNS, yapılandırma, otomasyon kodu ve lisans bağımlılıklarını yedekleyin.
3. RPO'ya göre sık, saldırgan bekleme süresine göre yeterince uzun saklama uygulayın.
4. Yedek başarısını günlük, örnek geri yüklemeyi aylık, uçtan uca hizmet kurtarmayı risk bazlı düzenli test edin.
5. Geri yükleme sırası ve veri tutarlılığı için uygulama sahibini sürece katın.
6. Ölçün: korunmayan kritik hizmet, son test yaşı, veri bütünlüğü hatası ve tek hata alanına bağlı kopya sayısı.

Ev kullanıcıları nasıl uygulayabilir?

Ana cihazdaki dosya “birinci kopya”, sürümlemeli bulut “ikinci”, bağlı tutulmayan harici disk veya farklı konum “üçüncü” olabilir. Bulut senkronizasyonunun yedek olmadığını unutmayın: şifreli/silinmiş dosyayı da senkronize edebilir. Kurtarma kodu ve şifreleme anahtarını yedekten ayrı güvenli yerde tutun.

Kontrol 10 – Patch Management (Yama Yönetimi)

Nedir?

Yama yönetimi; varlık ve sürüm envanteri, zafiyet değerlendirmesi, risk önceliği, test, dağıtım, başarısızlık/geri alma ve doğrulama döngüsüdür. “Her ay güncelleme yapmak”tan daha geniştir.

Neden gereklidir?

RaaS bağlı kuruluşları ve IAB'ler internete açık, bilinen ve istismar edilen zafiyetlerden yararlanabilir. Tüm CVE'leri aynı anda kapatmak gerçekçi değildir; internete açık ve CISA KEV'de yer alan zafiyetler yüksek öncelik taşır. S21

RaaS'a karşı nasıl korur?

• IAB'nin erişim elde edebileceği bilinen açıklığı kapatır.
• VPN, dosya aktarım, RMM ve sınır uygulamasındaki kitlesel istismar fırsatını azaltır.
• Yedek, hipervizör, kimlik ve güvenlik ürünlerinin yönetim düzlemini korur.
• Saldırganın ayrıcalık artırma ve güvenlik kontrolünü atlama seçeneklerini daraltır.

Tek başına yeterli mi?

Hayır. Sıfır gün, kimlik hırsızlığı, yanlış yapılandırma ve sosyal mühendislik yamayla çözülmez. Yama başarısız olabilir veya ürün destek dışı kalabilir. MFA, segmentasyon, en az yetki, WAF/erişim kısıtı ve izleme gibi telafi edici kontroller gerekir.

Kurumlarda nasıl uygulanır?

1. Varlık envanterini sürüm, iş sahibi, dışa açıklık, veri ve kritiklik ile ilişkilendirin.
2. Önceliği “CVSS en yüksek” yerine aktif istismar + internet açıklığı + kritik hizmet + ayrıcalık ile belirleyin.
3. Acil yama için küçük temsilî test halkası, hızlı onay ve belgeli geri alma hazırlayın.
4. Yama mümkün değilse sistemi kapatma, dış erişimi kaldırma, segmentasyon ve yoğun izleme için son tarihli risk kabulü oluşturun.
5. Tarama sonucunu dağıtım kaydıyla değil, hedefte sürüm/yapılandırma doğrulamasıyla kapatın.
6. Ölçün: KEV açık kalma süresi, internete açık desteksiz varlık, başarısız dağıtım ve süresi dolmuş istisna.

Ev kullanıcıları nasıl uygulayabilir?

İşletim sistemi, tarayıcı, ofis yazılımı, modem/router, NAS ve telefonlarda otomatik güncellemeyi açın. Destek süresi bitmiş cihazı internete açık kritik işlerde kullanmayın. Korsan/“kırılmış” yazılım güncellenemez ve ek risk taşır. Modem firmware'ini üretici desteği bitince cihaz yenileme ölçütü sayın.

Kontrol 11 – Network Segmentation (Ağ Segmentasyonu)

Nedir?

Segmentasyon; kullanıcı, sunucu, üretim, yedek, yönetim, sanallaştırma, tedarikçi ve güvenlik alanları arasındaki trafiği iş gereksinimine göre ayırıp varsayılan olarak sınırlar. Mikrosegmentasyon bu yaklaşımı iş yükü/uygulama düzeyine kadar inceltir. S19

NSA/CISA'nın ortak yanlış yapılandırma değerlendirmesi, yetersiz ağ ayrımı, geniş ayrıcalık ve zayıf izleme gibi tekrar eden sorunların saldırgan etki alanını büyüttüğünü gösterir. S20

Neden gereklidir?

Düz ağ, ele geçirilmiş tek cihazın çok sayıda sisteme erişmesini sağlar. RaaS etkisi özellikle yönetim, yedek ve hipervizör katmanına ulaşınca büyür. Segmentasyon saldırganın zamanını uzatır ve tespit fırsatı yaratır.

RaaS'a karşı nasıl korur?

• Kullanıcı ağından yönetim/backup sistemine doğrudan erişimi engeller.
• Bir tesis veya iş yükündeki olayın diğerlerine yayılmasını sınırlar.
• Doğu-batı trafiğini görünür ve anlamlı alarm hâline getirir.
• Kritik hizmeti güvenli izolasyon adası olarak çalıştırmayı kolaylaştırır.

Tek başına yeterli mi?

Hayır. Her yere açık istisna, ortak kimlik veya yanlış yönetim yolu segmentasyonu kağıt üzerinde bırakır. Segmentasyon veri sızıntısını veya ele geçirilmiş yetkili hesabı tek başına önlemez. Kimlik politikası, PAM, uygulama yetkilendirmesi ve günlükleme gerekir.

Kurumlarda nasıl uygulanır?

1. Kritik hizmet akışlarını keşfedin; yalnız IP/port değil kim, neden, veri ve yönetim yönünü belgeleyin.
2. Önce kullanıcı → yedek/hipervizör/dizin ve tedarikçi → tüm ağ gibi yüksek etkili yolları kapatın.
3. Yönetim erişimini ayrı atlama sunucusu/iş istasyonu ve phishing-resistant MFA üzerinden verin.
4. Güvenlik duvarı kuralına sahip, iş gerekçesi ve sona erme tarihi atayın.
5. Acil izolasyon senaryosunu üretim/klinik güvenlikle test edin; geri alma planı tutun.
6. Ölçün: “any-any” kural, kullanıcıdan yönetim düzlemine erişim, sahipsiz kural ve süresi dolmuş istisna.

Ev kullanıcıları nasıl uygulayabilir?

Modem/router'da misafir ağı açıp IoT, akıllı TV ve ziyaretçi cihazlarını ana bilgisayar/NAS ağından ayırın. Yönetim panelini internetten erişime kapatın; UPnP ve gereksiz port yönlendirmeyi azaltın. İş bilgisayarını riskli test veya korsan yazılım kullanılan cihazlarla aynı paylaşım hesabında tutmayın.

Kontrol 12 – Least Privilege (En Az Yetki)

Nedir?

En az yetki; insan, uygulama, servis, cihaz ve API'nin yalnız gerekli kaynağa, gerekli işlem için, gerekli süre boyunca erişmesidir. Rol, veri satırı/klasörü, ağ akışı ve işlem onayı düzeyinde uygulanır.

Neden gereklidir?

RaaS bağlı kuruluşu çoğu zaman mevcut yetkiyi kötüye kullanır. Her kullanıcının yerel yönetici olduğu, servis hesabının tüm veriyi okuyabildiği veya eski çalışanın rolünün kaldığı ortamda ilk erişim hızla geniş etkiye dönüşür.

RaaS'a karşı nasıl korur?

• Ele geçirilen hesabın veri ve sistem erişimini sınırlar.
• Toplu veri okuma, yazılım dağıtma ve güvenlik ayarı değiştirmeyi ayrı yetkiye bağlar.
• Kalıcı ayrıcalığı azaltarak saldırganın sessiz bekleme süresini zorlaştırır.
• Yetki dışı denemeleri yüksek değerli tespit sinyaline dönüştürür.

Tek başına yeterli mi?

Hayır. Kötü rol tasarımı, acil durumda aşırı “break-glass” kullanımı ve servis hesabı unutulması kontrolü bozar. En az yetki; PAM, JIT, erişim incelemesi, veri sınıflandırma ve segmentasyonla birlikte olmalıdır.

Kurumlarda nasıl uygulanır?

1. İnsan ve makine kimliklerini birlikte envantere alın; sahipsiz servis hesabını kapatın.
2. Rolü iş unvanından değil gerçek işlem ve veri gereksiniminden tasarlayın.
3. Yerel yönetici, bulut rolü ve hassas veri dışa aktarmayı kalıcı hak olmaktan çıkarın.
4. İşten ayrılma/rol değişikliğini kimlik ve tüm SaaS uygulamalarında otomatik tamamlayın.
5. Erişim incelemesinde yöneticiye “hepsini onayla” listesi değil kullanım ve risk kanıtı gösterin.
6. Ölçün: kullanılmayan yetki, sahipsiz kimlik, kalıcı admin, aşırı geniş servis hesabı ve geciken ayrılma kapatması.

Ev kullanıcıları nasıl uygulayabilir?

Günlük hesabı standart kullanıcı yapın. Telefon ve bilgisayar uygulamalarına gereksiz kişi, fotoğraf, mikrofon, depolama ve erişilebilirlik izni vermeyin. Bulut hesabındaki üçüncü taraf uygulama izinlerini temizleyin. Aile üyelerine ayrı kullanıcı profili açın.

Kontrol 13 – Threat Hunting (Tehdit Avcılığı)

Nedir?

Tehdit avcılığı, mevcut alarmların yakalamamış olabileceği saldırgan davranışını hipotez, veri ve analitik yöntemle proaktif aramadır. “Bir araç çalıştırıp kötü dosya bulma” değildir.

Neden gereklidir?

IAB erişimi ile ransomware etkisi arasında zaman olabilir. Meşru hesap/araç kullanımı düşük seviyeli alarm üretir. Güncel IOC ortaya çıktığında geçmiş telemetride geriye dönük arama erken erişimi ve kapsamı bulabilir.

RaaS'a karşı nasıl korur?

• MFA sıfırlama sonrası yönetim düzlemine erişim gibi zincirleri arar.
• EDR'siz/telemetrisiz cihaz, eski hesap ve anormal servis kimliğini ortaya çıkarır.
• Büyük veri toplama ile dış çıkış arasındaki ilişkiyi araştırır.
• Bir grup adından bağımsız, ATT&CK davranışlarına dayalı kalıcı tespit geliştirir. S22

Tek başına yeterli mi?

Hayır. Veri yoksa av yapılamaz; hipotezsiz geniş sorgu gürültüdür. Av ekibi müdahale yetkisi ve iş bağlamı olmadan bulguyu sonuca çeviremez. Sürekli izleme ve temel kontrollerin yerini tutmaz.

Kurumlarda nasıl uygulanır?

1. Hipotezi RaaS iş modeline bağlayın: “Ele geçirilmiş destek hesabı yedek konsoluna ulaşmış olabilir.”
2. Gerekli veri ve saklama süresini doğrulayın; veri boşluğunu sonuç olarak kaydedin.
3. Kimlik, EDR, ağ, bulut ve yedek zaman çizelgesini aynı UTC/zaman standardında birleştirin.
4. Bulguyu yeni SIEM/XDR kuralı, kontrol düzeltmesi veya olay müdahalesine dönüştürün.
5. Av sonuçlarını doğrulanmış, şüpheli, yanlış pozitif ve görünürlük eksikliği olarak sınıflandırın.
6. Ölçün: üretilen kalıcı tespit, kapanan görünürlük açığı ve bulunan yetkisiz erişim; yalnız sorgu sayısı değil.

Ev kullanıcıları nasıl uygulayabilir?

Ev kullanıcısının kurumsal tehdit avı yapması gerekmez. Hesap güvenlik sayfalarında cihaz/oturum geçmişini, posta yönlendirme kurallarını, bulut paylaşım bağlantılarını ve yüklenmiş uygulamaları periyodik kontrol etmek pratik karşılıktır. Şüpheli durumda kendi başına zararlı analizi yapmayın.

Kontrol 14 – Incident Response (Olay Müdahalesi)

Nedir?

Olay müdahalesi; hazırlık, tespit, analiz, kontrol altına alma, ortadan kaldırma, kurtarma ve ders çıkarma boyunca teknik ve iş kararlarını yöneten disiplindir. NIST SP 800-61 Rev. 3, müdahaleyi CSF 2.0 risk yönetimi içinde sürekli döngü olarak ele alır. S05

Neden gereklidir?

RaaS olayı aynı anda kimlik, veri, hizmet, hukuk, iletişim, sigorta ve insan güvenliği sorunu yaratır. Karar yetkisi önceden belirlenmezse ekipler delil siler, birbirini bekler veya saldırganın zaman baskısıyla kontrolsüz hareket eder.

RaaS'a karşı nasıl korur?

• Erken sinyali hızla doğrular ve yayılmayı sınırlar.
• İzolasyon ile kritik hizmet güvenliği arasındaki kararı yönetir.
• Veri sızıntısı ve şifreleme kapsamını ayrı değerlendirir.
• Kolluk, düzenleyici, hukuk ve iletişim süreçlerini teknik kurtarmayla paralel yürütür.

Tek başına yeterli mi?

Hayır. Plan temel kontrolleri ve kurtarma kapasitesini yaratmaz. Telefon numarası listesi tatbikat yapılmadan eskir. Müdahale; yedek, günlük, yetki, sözleşme, iş sürekliliği ve yönetim desteğine dayanır.

Kurumlarda nasıl uygulanır?

1. RaaS playbook'unu kimlik ihlali, veri sızıntısı, şifreleme, yedek kaybı ve tedarikçi olayını kapsayacak biçimde yazın.
2. Olay komutanı, teknik izolasyon yetkisi, kriz seviyesi ve yönetim kurulu çağrı eşiğini belirleyin.
3. Çevrimdışı iletişim, kişi listesi, kanıt formu, hukuk saklama talimatı ve alternatif kimlik erişimi hazırlayın.
4. Dış olay müdahale, hukuk ve kriz iletişimi sözleşmelerini olaydan önce yapın.
5. Masa başı ve teknik tatbikatta yardım masası, yedek, klinik/üretim ve tedarikçi senaryosu kullanın.
6. Ölçün: tespit, çağrı, izolasyon, kapsam ve kritik hizmet geri dönüş süreleri; açık düzeltici faaliyet yaşı.

Ev kullanıcıları nasıl uygulayabilir?

Basit bir plan tutun: interneti ayır, şüpheli cihazı kullanmayı bırak, güvenilir başka cihazdan kritik hesap oturumlarını kapat ve parolaları değiştir, yedekten önce profesyonel/üretici desteği al, banka/kimlik riskini bildir. Fidye notuyla iletişim kurmayın, şüpheli dosyayı silmeden fotoğraf/kayıt alın ve temiz olduğundan emin olmadığınız yedeği geri yüklemeyin.

Kontrol 15 – Business Continuity (İş Sürekliliği)

Nedir?

İş sürekliliği, teknoloji tamamen dönmeden kritik hizmeti kabul edilebilir kapasite ve güvenlikle sürdürme planıdır. İnsan, tesis, tedarikçi, iletişim, manuel süreç ve karar önceliğini kapsar.

Neden gereklidir?

RaaS'ın ödeme baskısı hizmet kesintisine dayanır. Yedek geri dönüş saatler/günler alabilir; veri doğrulama ve uygulama bağımlılığı daha uzun sürebilir. Change, CDK ve Synnovis olayları teknik kurtarmanın dışındaki nakit akışı, randevu ve manuel iş yükünü gösterir. S49 S52 S54

RaaS'a karşı nasıl korur?

• Kurumun fidye zaman baskısına dayanmasını sağlar.
• Kritik hizmeti güvenli degrade/manual modda sürdürür.
• Tedarikçi kesintisinde alternatif iletişim ve işlem kanalı verir.
• Teknik ekip kurtarma yaparken iş birimlerinin kontrolsüz gölge BT oluşturmasını önler.

Tek başına yeterli mi?

Hayır. Kağıt üzerindeki manuel süreç kapasite, dolandırıcılık ve veri bütünlüğü sorunları yaratabilir. Süreklilik planı saldırganı sistemden çıkarmaz veya veriyi geri getirmez. IR ve DR ile birlikte yürür.

Kurumlarda nasıl uygulanır?

1. “Her süreç kritik” demeyin; maksimum kabul edilebilir kesinti ve minimum hizmet seviyesini yönetim onayıyla sıralayın.
2. Kimlik, iletişim, ödeme, tedarikçi ve fiziksel emniyet bağımlılıklarını iş akışında gösterin.
3. Manuel form, numara serisi, çift kontrol ve sistem geri geldiğinde veri yeniden giriş/mutabakat yöntemini hazırlayın.
4. Çalışan iletişimi için kurumsal sistemden bağımsız doğrulanmış kanal tutun.
5. Tedarikçi kaybında alternatif sağlayıcı/karşılıklı yardım ve veri erişim koşulunu test edin.
6. Ölçün: tatbikatta sürdürülen gerçek kapasite, biriken iş, hata/dolandırıcılık ve personel dayanma süresi.

Ev kullanıcıları nasıl uygulayabilir?

Evde kritik belgelerin çevrimdışı kopyası, acil iletişim listesi, banka/sağlık/kimlik belgelerine alternatif erişim ve bir cihaz bozulduğunda kullanılabilecek güvenilir yedek cihaz planı iş sürekliliğinin karşılığıdır. Tek telefona bağlı MFA ve tüm belgeyi tek bulutta tutma riskini azaltın.

Kontrol 16 – Disaster Recovery (Felaket Kurtarma)

Nedir?

Felaket kurtarma, veri ve teknoloji hizmetlerini belirlenen RTO (geri dönüş süresi) ve RPO (kabul edilebilir veri kaybı) hedefleriyle yeniden kurma disiplinidir. RaaS senaryosunda “temiz ve güvenilir” olma koşulu klasik arızadan daha önemlidir.

Neden gereklidir?

Şifreleme, yedek kurcalama, kimlik ihlali ve sistem bütünlüğü kaybı aynı anda olabilir. Sadece sunucuyu açmak yetmez; saldırgan kalıcılığı, eski zafiyet, bozuk veri ve ele geçirilmiş sır geri taşınmamalıdır.

RaaS'a karşı nasıl korur?

• Fidye ödemeden kritik hizmeti geri getirme kapasitesi sağlar.
• Temiz oda ve aşamalı devreye alma ile yeniden saldırı riskini azaltır.
• Kimlik, DNS, sertifika, ağ ve veri tabanı sırasını önceden doğrular.
• Gerçek RTO/RPO'yu ölçerek yönetimin risk kararını kanıta dayandırır.

Tek başına yeterli mi?

Hayır. DR veri sızıntısını geri alamaz, hukuki yükümlülüğü kapatmaz ve manuel hizmeti tek başına sürdürmez. Yedek kötü/eksik olabilir. IR, iş sürekliliği, tehdit avı ve kimlik yenilemeyle birlikte gerekir.

Kurumlarda nasıl uygulanır?

1. Hizmet haritasına kimlik, DNS, NTP, sertifika, anahtar, ağ, depolama, veri tabanı, entegrasyon ve tedarikçiyi ekleyin.
2. Temiz oda ağı, güvenilir yönetim cihazı ve yeni kimlik/sır oluşturma süreci hazırlayın.
3. Geri yüklemeden önce yedek tarihi, kötü amaçlı kalıcılık ve zafiyet açısından tarama/doğrulama yapın.
4. Önce temel güven servisleri, sonra kritik uygulama, sonra daha düşük öncelikli iş yükü sırasını test edin.
5. Üretime açılma ölçütü: iş sahibi doğrulaması, veri tutarlılığı, güvenlik telemetrisi ve geri alma planı.
6. Ölçün: beyan edilen değil tatbikatta gerçekleşen RTO/RPO, başarısız bağımlılık ve manuel müdahale sayısı.

Ev kullanıcıları nasıl uygulayabilir?

İşletim sistemi kurtarma medyası/hesabı, cihaz şifreleme kurtarma anahtarı, lisans/kurulum bilgisi ve test edilmiş dosya yedeği tutun. Enfekte olabilecek tam sistem imajına körlemesine dönmek yerine temiz işletim sistemi kurup doğrulanmış kişisel dosyaları geri almak çoğu ev senaryosunda daha güvenlidir; uzman önerisine göre hareket edin.

Kontrol 17 – Güvenlik Farkındalık Eğitimleri

Nedir?

Farkındalık; çalışanı suçlamak değil, rolüne uygun riskleri tanıma, güvenli karar verme ve hızlı bildirme becerisi kazandırma programıdır. RaaS açısından yardım masası, yönetici, finans, tedarik, BT yöneticisi ve genel kullanıcı için içerik farklı olmalıdır.

Neden gereklidir?

Sosyal mühendislik yalnız e-posta bağlantısı değildir. Telefonla destek taklidi, MFA onay baskısı, faktör sıfırlama, tedarikçi kimliği ve acil yönetici talebi RaaS erişimine dönüşebilir. MGM/Caesars bağlamı ve Scattered Spider uyarısı, yardım masası süreçlerinin önemini gösterir. S61

RaaS'a karşı nasıl korur?

• Kullanıcı başlatmadığı MFA ve destek temasını erken bildirir.
• Yardım masası zayıf bilgi sorularıyla faktör sıfırlamaz.
• Yönetici, fidye notuna doğaçlama yanıt yerine olay komutasını çağırır.
• İş birimi, manuel süreçte veri bütünlüğü ve dolandırıcılık kontrolünü korur.

Tek başına yeterli mi?

Hayır. En iyi eğitimli kişi yorgunluk, baskı veya kusursuz taklit karşısında hata yapabilir. Sistem kullanıcı hatasını tolere edecek phishing-resistant MFA, en az yetki, güvenli varsayılan ve hızlı geri alma sunmalıdır. “Kullanıcı son savunma hattıdır” yaklaşımı tasarım sorumluluğunu yanlış yere taşır.

Kurumlarda nasıl uygulanır?

1. Yıllık genel video yerine rol bazlı kısa senaryo: yardım masası sıfırlama, yönetici acil onayı, tedarikçi dosyası, EDR uyarısı.
2. Simülasyonda utandırma/sıralama yapmayın; bildirim davranışını ödüllendirin ve süreç zayıflığını ölçün.
3. Çalışanın şüpheli olayı tek tık/tek numarayla bildirebilmesini sağlayın; geri bildirim verin.
4. Gerçek olay dersini kişisel veri paylaşmadan eğitime hızla ekleyin.
5. BT ve güvenlik yöneticilerine yedek/hipervizör/PAM özel tatbikatı uygulayın.
6. Ölçün: yalnız “tıklama oranı” değil bildirim süresi, doğru eskalasyon, yardım masası prosedür uyumu ve tekrar eden süreç açığı.

Ev kullanıcıları nasıl uygulayabilir?

Aile içinde basit kural belirleyin: destek görevlisi parola/MFA kodu istemez; acele ödeme veya uzaktan erişim talebi bağımsız numaradan doğrulanır; beklenmeyen ek açılmaz; şüpheli olay utanmadan hemen söylenir. Çocuk ve yaşlı kullanıcılar için tek güvenilir yardım kişisi ve doğrulama kelimesi belirlemek faydalıdır.

Kontrollerin birlikte çalışma örneği

Bir çalışan hesabının parolası çalındığında:

1. Phishing-resistant MFA ilk erişimi engeller.
2. Oturum başka yolla açılırsa Zero Trust yönetilmeyen cihazdan kritik kaynağı sınırlar.
3. En az yetki/PAM hesabın yönetim düzlemine ulaşmasını engeller.
4. Segmentasyon yedek ve hipervizör yolunu kapatır.
5. XDR/SIEM yeni cihaz + rol denemesi + nadir erişimi ilişkilendirir.
6. SOAR/IR oturumu iptal eder ve cihazı kontrollü izole eder.
7. Veri şifrelenirse immutable + 3-2-1 yedek/DR temiz geri dönüş sağlar.
8. İş sürekliliği kurtarma sürerken kritik hizmeti kontrollü biçimde devam ettirir.

Bu zincirde hiçbir kontrol kusursuz değildir; katmanlar birbirinin başarısızlığını sınırlar.

Kurumlar için 90 günlük RaaS savunma önceliği

Bu 90 günlük sıra, her sektör için aynı kontrol ayrıntısını dayatmaz; CISA'nın Cross-Sector Cybersecurity Performance Goals tabanını kurumun kritik hizmet ve riskine göre önceliklendirir. S59

Kontrol başarı ölçütleri

• Kimlik: MFA'sız başarılı oturum = 0 hedefi; phishing-resistant kapsam; sıfırlama istisnası.
• Ayrıcalık: Kalıcı admin ve ortak hesap azalması; JIT kullanım oranı.
• Görünürlük: Kritik soruyu yanıtlama süresi; telemetri kör noktası.
• Yedek: Gerçek geri yükleme başarısı, bütünlük, RTO/RPO ve ayrı hata alanı.
• Müdahale: Tespit–çağrı–izolasyon–kapsam süreleri; tatbikat bulgusu kapanma yaşı.
• Süreklilik: Manuel mod kapasitesi, hata oranı ve sürdürülebilir personel süresi.
• Tedarikçi: Kritik bağımlılık için alternatif, bildirim süresi ve tatbikat kanıtı.

RaaS açısından neden önemli?

RaaS, kimlikten yedeğe ve veri sızıntısından iş kesintisine uzanan çok aşamalı bir ekonomik modeldir. Bu bölüm her kontrolü “nedir, neden gerekir, nasıl korur, tek başına yeterli mi, kurum ve evde nasıl uygulanır” şablonuyla ele alarak savunmayı sloganlardan ölçülebilir, katmanlı bir dayanıklılık programına dönüştürür.

Olay Sonrası Yapılması Gerekenler

Zaman çizelgesinden önce üç kural

1. İnsan güvenliği ve kritik hizmet önce gelir. Hastane, üretim, enerji veya ulaşım ortamında teknik izolasyonun fiziksel/klinik etkisi değerlendirilir.
2. Şifreleme ile veri sızıntısını ayrı iş akışı olarak yönetin. Sistem geri dönse bile bildirim ve mağdur riski devam edebilir.
3. Tek karar günlüğü ve tek komuta kullanın. Kimin neyi, ne zaman, hangi kanıtla yaptığı kaydedilir. NIST SP 800-61 Rev. 3 ve CISA #StopRansomware rehberi hazırlık, kontrol altına alma ve kurtarmayı kurumsal risk yönetimiyle birleştirir. S02 S05

Bu zaman çizelgesi uyarlanmalıdır: Yasal bildirim süreleri ülke, sektör, veri türü ve sözleşmeye göre değişir. Kurum kendi hukuk danışmanı, ulusal CERT/kolluk, düzenleyici ve sigortacı şartlarını önceden playbook'a işlemelidir.

Rol ve karar tablosu

İlk 5 dakika

1. Olayı doğrula ve seviyelendir

• Alarmın kaynağını, zamanı, varlığı ve ilk görülen davranışı kaydedin.
• Fidye notu varsa ekran görüntüsü ve dosya konumunu koruyun; saldırganla temas kurmayın.
• Kimlik, yedek/hipervizör, EDR kurcalama, toplu dosya değişimi veya veri çıkışı varsa yüksek/kritik seviye değerlendirin.
• İnsan güvenliği, klinik bakım, fiziksel üretim ve acil hizmet etkisini hemen sorun.

2. Olay komutasını ve temiz iletişimi başlat

• Olay komutanını ve teknik lideri çağırın.
• Şüpheli kurumsal e-posta/mesajlaşma yerine önceden hazırlanmış bağımsız iletişim kanalına geçin.
• Tek olay numarası, zaman damgası ve karar günlüğü açın.
• Durum paylaşım ritmini belirleyin; örneğin kritik aşamada 15 dakikada bir.

3. Etkiyi sınırlayan ilk güvenli hamle

• Doğrulanmış şüpheli cihazı EDR ile izole edin veya ağ bağlantısını kontrollü kesin.
• Ele geçirilmiş olduğu güçlü biçimde düşünülen hesabı askıya alın; aktif oturumları ve belirteçleri iptal edin.
• Fiziksel/klinik etkisi bilinmeyen sistemleri rastgele kapatmayın.
• Cihazı güçten kesmek uçucu kanıtı kaybettirebilir; ancak şifreleme hızla sürüyorsa kontrol altına alma önceliği ağır basabilir. Kararı ve gerekçeyi kaydedin.

4. Yedek ve yönetim düzlemini koru

• Yedek, hipervizör, PAM, RMM, bulut ve kimlik konsolunda aktif oturum/değişiklik olup olmadığını kontrol edin.
• Yedek silme/retention değişikliğini dondurun; ayrı yönetim kanalını koruyun.
• Yedek işlerini körlemesine durdurmayın: bozuk veriyi çoğaltma ile gerekli kurtarma noktası arasındaki dengeyi yedek sorumlusu değerlendirsin.

İlk 5 dakikada yapılmaması gerekenler

• Fidye notunu silmek veya faille bireysel cihazdan yazışmak.
• “Yanlış alarm” kanıtı olmadan güvenlik aracını kapatmak.
• Kapsam bilinmeden tüm parolaları aynı anda değiştirip saldırgana müdahaleyi duyurmak.
• Kurumsal sohbette doğrulanmamış fail adı ve veri kapsamı paylaşmak.
• Yedeği kontrol etmeden üretim sistemine bağlamak.

İlk 30 dakika

Kapsamın ilk çemberini çiz

• Etkilenen kimlik, cihaz, segment, uygulama, veri, tesis ve tedarikçiyi listeleyin.
• İlk görülen zaman ile şifreleme/fidye notu zamanı arasındaki boşluğu araştırın.
• Aynı hesap veya göstergenin diğer sistemlerdeki hareketini SIEM/XDR üzerinden arayın.
• EDR'siz veya günlük göndermeyen kritik varlıkları “temiz” değil “bilinmiyor” olarak işaretleyin.

Kimliği kontrol altına al

• Şüpheli insan hesabında parola değişimiyle birlikte tüm oturum, refresh token, cihaz kaydı ve uygulama parolasını iptal edin.
• Yetkisiz MFA yöntemi, OAuth izni, posta kuralı, erişim anahtarı ve rol değişikliğini geri alın.
• Domain/cloud admin hesabında kitlesel değişimden önce güvenilir yönetim cihazı ve temiz iletişim oluşturun.
• Servis hesabını aniden döndürmenin hizmet etkisini değerlendirin; yüksek riskli sırları öncelik ve kontrollü planla yenileyin.

Yayılmayı durdur

• Etkilenen segmentler arasında gereksiz doğu-batı trafiğini geçici olarak kapatın.
• Kullanıcı ağından yedek, hipervizör, RMM ve kimlik yönetimine erişimi kesin.
• Bilinen kötü hedef/göstergeleri uç nokta, DNS, proxy ve güvenlik duvarında uygulayın; meşru hizmet yanlış pozitifini kontrol edin.
• Saldırganın kullandığı düşünülen tedarikçi bağlantısını sözleşmedeki acil kesme prosedürüyle durdurun.

Delili koru

• Kimlik, EDR, güvenlik duvarı, DNS, proxy, e-posta, bulut, yedek ve hipervizör günlüklerini ayrı depoya kopyalayın/koruma kilidi uygulayın.
• Saat dilimini ve sistem saat sapmasını kaydedin.
• Şüpheli cihaz görüntüsü/bellek toplama kararını uzman ekibe verin; kontrol altına almayı geciktirmeyin.
• Dosya hash'i veya IOC paylaşılacaksa kişisel/sır veri içermediğini doğrulayın.

İş sürekliliğini tetikle

• Kritik hizmet sahibi manuel/degrade moda geçiş kararı versin.
• Kimlik, telefon, e-posta veya tedarikçi portalı çalışmıyorsa alternatif iş akışını başlatın.
• Manuel işlemlerde benzersiz numara, çift onay ve sonradan mutabakat kaydı tutun.

İlk saat

Teknik ve iş etkisini ortak tabloya çevir

Kriz paydaşlarını etkinleştir

• Hukuk, gizlilik, uyum, iletişim, sigorta ve insan kaynaklarını olay seviyesine göre çağırın.
• Ulusal CERT/kolluk ve sektör düzenleyicisi için ön bildirim gereksinimini değerlendirin.
• Dış olay müdahale ve kriz iletişimi sözleşmesini etkinleştirin.
• Yönetim kuruluna kesinlik derecesiyle kısa durum verin: bilinen, bilinmeyen, sonraki karar ve destek ihtiyacı.

Veri sızıntısını araştır

• Hassas veri erişimi, arşivleme, dış paylaşım ve ağ çıkışını zaman çizelgesinde ilişkilendirin.
• Failin “veri aldım” örneğini tek başına kapsam kanıtı saymayın; kurum envanteri ve günlüklerle doğrulayın.
• Şifreleme yoksa olayı kapatmayın; data-extortion senaryosu olabilir.
• Hukuki ayrıcalığı ve delil saklama yükümlülüğünü danışmanla yönetin.

Kurtarma stratejisini seç

• Temiz oda/ayrı ağ ve güvenilir yönetim kimliği oluşturun.
• En son yedeğin yanında daha eski doğrulanmış kurtarma noktalarını koruyun.
• Önce kimlik/DNS/zaman/sertifika gibi temel hizmetlerin güvenilirliğini değerlendirin.
• Üretime dönüşü tek büyük açılış yerine kontrollü dalgalara ayırın.

İlk gün

Kapsam ve kök neden üzerinde çalış

• İlk erişim, ayrıcalık, yayılma, veri erişimi, sızdırma ve etki için ayrı kanıt çizgileri oluşturun.
• Tek bir zafiyet veya kullanıcı tıklamasını erken “kök neden” ilan etmeyin; süreç ve kontrol başarısızlıklarını bulun.
• Eski/unutulmuş hesap, tedarikçi erişimi, MFA sıfırlama ve yönetim konsolu değişikliklerini inceleyin.
• İlgisiz sistemleri “etkilenmedi” demeden önce telemetri yeterliliğini belirtin.

Kontrollü kurtarmaya başla

1. Temiz yönetim cihazı ve yeni ayrıcalıklı kimlik.
2. Kimlik, DNS, NTP, sertifika/anahtar gibi güven hizmetleri.
3. Ağ segmentasyonu ve güvenlik telemetrisi.
4. Kritik uygulama ve veri tabanı; veri tutarlılığı kontrolü.
5. İş sahibi kabulü ve sınırlı kullanıcı açılışı.
6. Daha düşük öncelikli sistemler.

Her aşamada eski sır/oturum iptalini, yama ve yanlış yapılandırma düzeltmesini, EDR/log akışını ve geri alma kararını doğrulayın.

İletişim ve bildirim

• Çalışanlara ne yapmaları, hangi kanalın güvenilir olduğu ve neyi paylaşmamaları gerektiğini söyleyin.
• Kamu açıklamasında olay tarihi, doğrulanan hizmet etkisi, alınan koruma adımı ve sonraki güncelleme zamanı yer alsın.
• “Hiç veri çalınmadı” gibi erken kesinlikten kaçının; “şu anda kanıt yok, inceleme sürüyor” kanıt dilini kullanın.
• Etkilenen kişilere eyleme dönük destek sunun; suçlayıcı veya teknik jargonlu metin kullanmayın.
• Bildirim zamanlamasını yerel hukuk ve düzenleyici şartlara göre belgeleyin.

Fidye/temas yönetişimi

Bu rehber saldırganla pazarlık talimatı vermez. Yönetim, ödeme düşünülüyorsa hukuk, yaptırım, kolluk, sigorta, insan güvenliği, veri sızıntısı, teknik kurtarma ve etik riskleri birlikte ele almalıdır. Ödeme; veri silme, yayımlamama veya tekrar saldırmama garantisi değildir. Teknik kurtarma ve bildirim çalışmaları temastan bağımsız sürmelidir.

İlk hafta

Aşamalı hizmet geri dönüşü

• Her hizmet için güvenlik, veri bütünlüğü, iş kabulü ve izleme kapısını tamamlayın.
• Geri dönen sistemde yüksek hassasiyetli tehdit avcılığı yürütün.
• Manuel işlemleri sisteme aktarırken çift kayıt, sahtecilik ve eksik işlem mutabakatı yapın.
• Birikmiş iş yükü ve çalışan yorgunluğu için vardiya/psikososyal destek planlayın.

Kimlik ve sır yenileme

• İnsan ve servis hesaplarını risk sırasına göre döndürün.
• Sertifika, API anahtarı, SSH anahtarı, uygulama sırrı, yedek ve ağ cihazı kimliklerini unutmayın.
• Eski belirteç/cihaz kayıtlarını iptal edin; yeniden kayıt işlemini güvenilir cihazdan yapın.
• Tedarikçi erişimini yeni koşul ve süreyle tekrar açın; eski güveni otomatik geri getirmeyin.

Veri ve mağdur yönetimi

• Etkilenen veri kümelerini sahip, kişi, ülke, hassasiyet ve bildirim gereksinimiyle haritalayın.
• Failin yayımladığı/verdiği örneği indirme ve işlemede hukuk, güvenlik ve mahremiyet kontrolü uygulayın; sızıntı sitesine gereksiz erişmeyin.
• Dolandırıcılık/kimlik riski olan kişilere açık, ölçülü ve pratik destek sunun.
• Üçüncü taraflara ait veride bildirim ve sorumluluk zincirini sözleşmeyle doğrulayın.

Geçici kontrolü kalıcı risk azaltımına çevir

• Acil güvenlik duvarı kuralı, kapatılan servis ve manuel prosedüre sahip/son tarih verin.
• Olay sırasında bulunan MFA'sız yol, EDR kör noktası, sahipsiz varlık ve ortak hesabı kapatın.
• Kurtarma sırasında yapılan yeni mimariyi belgeleyin; “geçici ama kalıcı” gölge yapı bırakmayın.

İlk ay

Olay sonrası inceleme

İnceleme suçlama toplantısı değildir. Zaman çizelgesi ve kontrol başarısızlığı üzerinden şu soruları yanıtlar:

• İlk önlenebilir ve ilk tespit edilebilir an hangisiydi?
• Alarm neden görüldü/görülmedi; görüldüyse neden eskale edilmedi?
• Saldırgan hangi güven ilişkisiyle etki alanını büyüttü?
• Yedek ve kurtarma hedefleri gerçek testte tuttu mu?
• Hangi manuel süreç güvenli ve sürdürülebilirdi?
• Tedarikçi, hukuk, iletişim ve yönetim kararında hangi gecikme oldu?
• Hangi kontrol değişikliği saldırganın beklenen getirisini en çok düşürür?

Düzeltici faaliyet programı

Her bulguya aşağıdaki alanlar atanır:

“Kullanıcı eğitilecek”, “MFA artırılacak” veya “yedekler kontrol edilecek” kapanabilir faaliyet değildir. Örnek doğrulanabilir sonuç: “İnternete açık tüm yönetim portallarında 30 gün içinde FIDO2 zorunlu; MFA'sız başarılı oturum sıfır; yardım masası sıfırlaması çift onay ve bağımsız alarm ile test edildi.”

Kurumsal ve dış takip

• Düzenleyici/etkilenen kişi bildirimlerini yeni kanıta göre güncelleyin.
• Sigorta talebi, sözleşmesel rücu ve tedarikçi iyileştirme planını yönetin.
• Delil saklama ve dava/inceleme süresini hukukla belirleyin.
• Kolluk/CERT ile paylaşılabilir gösterge ve dersleri gizlilik kontrolünden geçirerek paylaşın.
• Yönetim kuruluna olay maliyeti, hizmet etkisi, düzeltme durumu ve kalan risk raporu verin.
• Altı ve on iki ay sonra düzeltmelerin hâlâ çalıştığını yeniden test edin.

İzolasyon mu, kapatma mı?

Delil ve gizlilik kontrol listesi

• Kim, ne zaman, hangi yetkiyle topladı?
• Saat dilimi ve sistem saat farkı kaydedildi mi?
• Orijinal veri korunup analiz kopyası mı kullanıldı?
• Kişisel veri ve sır gereksiz kişilere/kanallara yayıldı mı?
• Hash/zincirleme kayıt ve erişim günlüğü tutuldu mu?
• Hukuki saklama/ayrıcalık talimatı uygulandı mı?
• Dış sağlayıcıya gönderim sözleşme ve ülke aktarımı açısından onaylandı mı?
• Delil toplama kontrol altına almayı geciktirdi mi; gerekçe kaydedildi mi?

Başarı ölçütü

Olay müdahalesi “tüm sistemler yeşil” olduğunda bitmez. Başarı:

• Kritik hizmetin güvenli ve ölçülmüş sürede dönmesi.
• Kimlik ve yönetim düzleminin yeniden güvenilir hâle gelmesi.
• Veri sızıntısı kapsamının kanıta dayalı belirlenmesi.
• Etkilenen kişilerin zamanında ve dürüst bilgilendirilmesi.
• Kök neden ve yapısal zayıflıkların sahipli faaliyetlerle kapanması.
• Aynı saldırı yolunun negatif testte artık çalışmaması.

RaaS açısından neden önemli?

RaaS operatörü zaman, belirsizlik ve hizmet kesintisini ödeme baskısına çevirir. Bu bölüm ilk beş dakikadan ilk aya kadar karar yetkisini, kimlik ve yedek korumasını, delil/bildirim sürecini ve temiz kurtarmayı zaman çizelgesine bağlayarak saldırganın kriz avantajını azaltır.

RaaS Terimleri Sözlüğü

Bu sözlük 300 terimi saldırı öğretmeden, RaaS ekosistemi, tespit, müdahale ve dayanıklılık bağlamında tanımlar. Bir terimin genel siber güvenlikte daha geniş anlamı olabilir; burada RaaS'ı anlamaya yarayan yönü öne çıkarılmıştır.

A. Ekosistem, gasp ve operasyon kavramları

G001 — RaaS (Ransomware as a Service): Ransomware yazılımı ve gasp altyapısının operatör tarafından bağlı kuruluşlara sunulduğu, gelir veya ücret paylaşımına dayalı suç hizmeti modeli.

G002 — Ransomware (fidye yazılımı): Veriyi ya da sistemi erişilemez kılarak veya veri yayımlama tehdidiyle ödeme baskısı oluşturan kötü amaçlı yazılım/operasyon sınıfı.

G003 — Affiliate (bağlı kuruluş): RaaS platformunu kullanarak hedefe erişen ve saldırı/gasp sürecini yürüten, gelirden pay alan aktör.

G004 — RaaS operatörü: Şifreleyici, panel, ödeme, yayın veya destek altyapısının bir bölümünü geliştiren ve affiliate programını yöneten aktör.

G005 — Ransomware geliştiricisi: Şifreleme veya ilgili yazılım bileşenlerini üretir; hedefe erişen kişiyle aynı aktör olmak zorunda değildir.

G006 — Initial Access Broker (IAB): Önceden ele geçirilmiş kurum erişimini başka suç aktörlerine satan veya devreden ilk erişim aracısı.

G007 — Access-as-a-Service: Geçerli hesap, uzak erişim veya ele geçirilmiş sistem erişiminin hizmet gibi kiralanması/satılması; RaaS'ın girdilerinden biri olabilir.

G008 — Mağdur kuruluş: RaaS bağlantılı erişim, veri hırsızlığı, şifreleme veya gaspın hedefi olan tüzel/kurumsal yapı.

G009 — Kampanya: Ortak amaç, zaman, altyapı veya davranışla ilişkilendirilen birden çok kötü niyetli faaliyet/olay kümesi.

G010 — Intrusion (sızma): Yetkisiz aktörün bir kimlik, cihaz, uygulama veya ağa erişmesi; ransomware etkisinden önce başlayabilir.

G011 — Extortion (gasp): Zarar verme, hizmeti durdurma veya veri yayımlama tehdidiyle para ya da başka çıkar talep edilmesi.

G012 — Tekli gasp: Genellikle şifre çözme anahtarı karşılığında ödeme baskısına dayanan ransomware modeli.

G013 — Çift gasp: Veri hırsızlığı/yayın tehdidi ile sistem şifrelemeyi aynı olayda birleştiren baskı modeli.

G014 — Üçlü gasp: Şifreleme ve veri sızıntısına ek olarak müşteri/çalışan baskısı veya hizmet engelleme gibi üçüncü baskı katmanı kullanılması.

G015 — Data-theft-only extortion: Şifreleme yapmadan yalnızca çalınan veriyi yayımlama/satma tehdidiyle yürütülen gasp.

G016 — Şifreleme: Verinin anahtar olmadan okunamayacak biçime dönüştürülmesi; meşru koruma teknolojisi olsa da ransomware bunu erişilebilirliği bozmak için kötüye kullanır.

G017 — Decryptor (şifre çözücü): Şifrelenmiş veriyi uygun anahtarla geri açmaya çalışan araç; çalışması tam ve güvenli kurtarmayı garanti etmez.

G018 — Ransom note (fidye notu): Saldırganın ödeme ve iletişim talebini ilettiği mesaj; adli kapsam veya veri sızıntısı kanıtı değildir.

G019 — Data Leak Site (DLS): Suç aktörünün mağdur adı veya çalınan veri örneğini yayımlayarak baskı kurduğu site; kayıtları doğrulanmış olay sayımı değildir.

G020 — Big-game hunting: Çok sayıda küçük hedef yerine kesinti maliyeti ve ödeme baskısı yüksek kurumlara odaklanma eğilimi.

G021 — Fırsatçı hedefleme: Belirli bir kurumu uzun süre seçmek yerine açık hizmet, çalınmış hesap veya yaygın zafiyet üzerinden erişilebilen hedefe yönelme.

G022 — Human-operated ransomware: Kararların önemli bölümünün insan operatörce verildiği, hedef ortamına uyarlanan ransomware operasyonu.

G023 — Malware: Sistemin gizlilik, bütünlük veya erişilebilirliğine zarar vermek için tasarlanan/kullanılan kötü amaçlı yazılım genel sınıfı.

G024 — Payload: Bir sızma zincirinin hedef sistemde çalıştırmak istediği etkili bileşen; ransomware şifreleyicisi bunlardan biri olabilir.

G025 — Loader: Başka bir kötü amaçlı bileşeni sisteme getiren veya çalıştıran yazılım; RaaS'tan bağımsız suç hizmeti de olabilir.

G026 — Dropper: Kendi içindeki başka bir bileşeni hedef sisteme bırakan yazılım; savunmada süreç/dosya davranışıyla incelenir.

G027 — Initial access (ilk erişim): Saldırganın kurumdaki ilk kullanabilir kimlik, cihaz, uygulama veya bağlantıyı elde ettiği aşama.

G028 — Privilege escalation (yetki artırma): Sınırlı erişimin daha geniş yönetim veya veri yetkisine dönüştürülmesi.

G029 — Lateral movement (yatay hareket): Ele geçirilen bir noktadan başka cihaz, hesap veya hizmetlere geçerek etki alanını büyütme.

G030 — Discovery (keşif): Ortamdaki kimlik, sistem, ağ, güvenlik veya veri yapısını anlamaya yönelik davranışlar.

G031 — Collection (toplama): Gasp veya başka amaçla değerli bilgilerin seçilip bir araya getirilmesi.

G032 — Staging (hazırlama alanı): Toplanan verinin dışarı çıkarılmadan önce geçici konumda düzenlenmesi veya gruplanması.

G033 — Exfiltration (veri sızdırma): Verinin kurumun kontrol sınırı dışına yetkisiz biçimde çıkarılması.

G034 — Impact (etki): Saldırgan davranışının hizmet, veri, finans, insan güvenliği veya itibar üzerinde oluşturduğu sonuç.

G035 — Persistence (kalıcılık): Oturum veya sistem yeniden başlasa bile erişimi sürdürebilecek yetkisiz mekanizma/kimlik bırakılması.

G036 — Defense evasion (savunmadan kaçınma): Güvenlik araçları, günlükler veya analist tespitinden saklanmaya dönük davranış sınıfı.

G037 — Command and Control (C2): Ele geçirilmiş sistemlerle dış aktör arasında komut/iletişim kanalı; meşru hizmetler de kötüye kullanılabilir.

G038 — Dwell time: İlk yetkisiz erişim ile tespit/etki arasındaki süre; uzunluğu geçmiş telemetri ihtiyacını belirler.

G039 — Kill chain: Saldırı faaliyetlerini aşamalara ayıran kavramsal model; savunmada müdahale noktalarını göstermek için kullanılır.

G040 — TTP: Tehdit aktörünün taktik, teknik ve prosedürleri; marka IOC'sinden daha kalıcı davranış bilgisi sağlayabilir.

G041 — IOC (Indicator of Compromise): Kötü etkinlikle ilişkilendirilen hash, alan adı, IP, dosya veya kayıt gibi gösterge; tek başına bağlam/kanıt değildir.

G042 — IOA (Indicator of Attack): Belirli bir sabit değerden çok kötü niyetli davranış niyetini veya zincirini gösteren saldırı işareti.

G043 — Threat actor (tehdit aktörü): Yetkisiz siber faaliyeti yürüten kişi, ekip veya yapı; marka adıyla bire bir eşleşmeyebilir.

G044 — Cybercrime ecosystem: Erişim, kimlik, yazılım, barındırma, gasp ve para akışı gibi uzmanlaşmış suç hizmetlerinin oluşturduğu pazar.

G045 — Rebrand (yeniden markalama): Aktör veya hizmetin eski adını bırakıp yeni marka altında faaliyet göstermesi; örgütsel sürekliliği tek başına kanıtlamaz.

G046 — Affiliate migration: Bağlı kuruluşun bir RaaS programından başka programa geçmesi; aynı davranışların farklı marka altında görülmesine yol açar.

G047 — Exit scam: Operatörün bağlı kuruluş veya müşterilerin payını/varlığını alıp hizmeti kapatarak kaçması.

G048 — Disruption operation: Kolluk ve ortakların suç altyapısı, alan adı, sunucu, anahtar, para veya personel üzerinde faaliyet kapasitesini bozması.

G049 — Takedown: Kötü niyetli altyapının yetkili süreçle kapatılması veya ele geçirilmesi; aktörlerin tamamının yakalandığı anlamına gelmez.

G050 — Attribution (atıf): Bir olayı belirli aktör, marka veya ülkeyle kanıta dayalı ilişkilendirme; farklı güven düzeyleriyle ifade edilmelidir.

B. Kimlik ve erişim güvenliği

G051 — Credential (kimlik bilgisi): Hesaba veya hizmete erişim sağlayan parola, anahtar, token, sertifika gibi kanıt.

G052 — Credential stuffing: Başka bir sızıntıdan alınan kullanıcı adı/parola çiftlerini çok sayıda hizmette deneme; parola yeniden kullanımını hedefler.

G053 — Password spraying: Az sayıda yaygın parolayı çok sayıda hesapta deneyerek kilitleme eşiklerinden kaçınmaya çalışma.

G054 — Brute force: Çok sayıda parola/anahtar olasılığını sistematik deneme; hız sınırlama ve güçlü kimlik doğrulama ile zorlaştırılır.

G055 — Phishing: Kullanıcıyı sahte iletişim veya sayfayla kimlik bilgisi/eylem vermeye ikna etmeye çalışan sosyal mühendislik.

G056 — Spear phishing: Belirli kişi veya kuruma göre özelleştirilmiş kimlik avı.

G057 — Vishing: Telefon/ses kanalı üzerinden destek, yönetici veya kurum taklidiyle bilgi/eylem elde etmeye çalışma.

G058 — Smishing: SMS/mesaj kanalıyla yapılan kimlik avı ve sosyal mühendislik.

G059 — MFA: Oturum için en az iki bağımsız kanıt isteyen çok faktörlü kimlik doğrulama.

G060 — Phishing-resistant MFA: Kanıtı gerçek hizmet alanına/cihaza kriptografik bağlayarak sahte sayfaya kod teslim etmeyen MFA.

G061 — Passkey: FIDO standartlarına dayalı, kullanıcı cihazında özel anahtar tutan ve parola yerine kullanılabilen kimlik doğrulama yöntemi.

G062 — FIDO2: Açık anahtarlı, phishing-resistant kimlik doğrulamayı destekleyen FIDO Alliance ve WebAuthn/CTAP standart kümesi.

G063 — WebAuthn: Tarayıcı ve çevrimiçi hizmetler için açık anahtarlı kimlik doğrulama web standardı.

G064 — OTP: Tek kullanım için üretilen kısa doğrulama kodu; MFA'sızlıktan iyidir fakat kimlik avına aktarılabilir.

G065 — MFA push fatigue: Kullanıcıyı art arda onay bildirimiyle yorup yanlışlıkla kabul ettirmeye çalışma.

G066 — Number matching: MFA ekranında görülen sayının oturum cihazına girilmesini isteyerek kör onayı azaltan yöntem; phishing-resistant değildir.

G067 — Session token: Başarılı oturumdan sonra kullanıcının yeniden parola girmeden erişmesini sağlayan belirteç; çalınırsa MFA sonrası oturum kötüye kullanılabilir.

G068 — Refresh token: Kısa ömürlü erişim tokenlarını yenileyen uzun ömürlü belirteç; olayda ayrıca iptal edilmelidir.

G069 — Cookie theft: Tarayıcı oturum çerezinin çalınarak mevcut oturumun taklit edilmesi.

G070 — Single Sign-On (SSO): Bir kimlik sağlayıcı üzerinden birden çok uygulamaya erişim; güvenliği merkezileştirir, ihlal etkisini de büyütebilir.

G071 — Identity Provider (IdP): Kimliği doğrulayıp uygulamalara oturum/iddia sağlayan merkezi hizmet.

G072 — Federation (federasyon): Farklı kurum veya sistemlerin kimlik doğrulama güvenini protokol ve sözleşmeyle paylaşması.

G073 — OAuth: Uygulamaya parola vermeden belirli kaynaklara yetki devretmeyi sağlayan standart; kötü niyetli izin riski taşır.

G074 — OAuth consent: Kullanıcının uygulamaya erişim izni vermesi; geniş ve kalıcı izinler RaaS öncesi veri/posta erişimine dönüşebilir.

G075 — Service account: Uygulama veya hizmetin otomatik çalışması için kullanılan kimlik; etkileşimli kullanım ve aşırı yetki sınırlandırılmalıdır.

G076 — Machine identity: İnsan olmayan iş yükü, cihaz veya hizmeti doğrulayan kimlik.

G077 — API key: Uygulamanın API'ye erişimini tanımlayan anahtar; sızarsa parola gibi kötüye kullanılabilir.

G078 — Secret (sır): Parola, token, anahtar veya bağlantı bilgisinin gizli tutulması gereken ortak adı.

G079 — Digital certificate (dijital sertifika): Açık anahtar ile kimlik/alan arasındaki bağı imzalayan belge; yönetim ve yenileme güveni önemlidir.

G080 — Private key (özel anahtar): İmza veya şifre çözme için gizli tutulan kriptografik anahtar; çalınması kimlik taklidine yol açabilir.

G081 — PAM: Ayrıcalıklı hesap ve oturumları kasaya alma, süreli yetki, izleme ve onayla yöneten disiplin.

G082 — Just-in-Time (JIT) access: Yetkinin yalnız onaylanan kısa süre için verilmesi ve otomatik geri alınması.

G083 — Just Enough Administration (JEA): Yöneticinin tüm haklar yerine yalnız belirli yönetim işlemlerini yapabilmesi ilkesi.

G084 — Least privilege: Kimliğe yalnız gerekli kaynak, işlem ve süre kadar yetki verme.

G085 — RBAC: Yetkinin görev/rol kümelerine göre verildiği rol tabanlı erişim kontrolü.

G086 — ABAC: Erişimin kullanıcı, cihaz, kaynak ve bağlam niteliklerine göre değerlendirildiği nitelik tabanlı kontrol.

G087 — Privileged account: Sistem, güvenlik, veri veya politika üzerinde geniş değişiklik yapabilen yüksek yetkili hesap.

G088 — Break-glass account: Normal kimlik hizmeti çalışmadığında acil erişim için ayrılmış, sıkı korunan ve her kullanımı alarmlanan hesap.

G089 — Conditional access: Oturum kararını kimlik, cihaz, konum, risk ve uygulama koşullarına bağlayan politika.

G090 — Device trust: Erişim kararında cihazın kaydı, yönetimi, şifrelemesi ve güvenlik sağlığına duyulan doğrulanmış güven.

G091 — Account takeover: Hesabın yetkisiz aktörce kontrol edilmesi; RaaS ilk erişiminin sık girdilerindendir.

G092 — Identity proofing: Hesap açma veya kurtarmada kişinin iddia ettiği kimliğin güvenilir kanıtla doğrulanması.

G093 — Help-desk reset: Destek masasının parola/MFA kurtarma işlemi; sosyal mühendisliğe karşı yüksek güvenli prosedür gerektirir.

G094 — Dormant account: Uzun süre kullanılmayan fakat erişimi açık hesap; saldırgan için düşük görünürlüklü yol olabilir.

G095 — Orphaned account: Sorumlusu/iş sahibi kalmamış hesap veya servis kimliği.

G096 — Credential rotation: Parola, anahtar ve tokenların kontrollü biçimde yenilenmesi ve eskilerinin iptal edilmesi.

G097 — Session revocation: Aktif oturum ve belirteçlerin geçersiz kılınması; yalnız parola değişiminden daha geniş olay adımıdır.

G098 — Impossible travel: Kısa sürede fiziksel olarak bağdaşmayan konumlardan oturum işareti; VPN gibi meşru nedenlerle doğrulama gerekir.

G099 — Legacy authentication: Modern MFA/koşullu erişim kontrollerini desteklemeyen eski kimlik doğrulama yolu.

G100 — Identity perimeter: Ağ çevresi yerine kullanıcı, cihaz, oturum ve yetkiyi temel güven sınırı kabul eden yaklaşım.

C. Varlık, zafiyet, ağ ve altyapı

G101 — Attack surface (saldırı yüzeyi): Yetkisiz aktörün erişebileceği kimlik, cihaz, uygulama, hizmet, veri ve güven ilişkilerinin toplamı.

G102 — External Attack Surface Management (EASM): İnternetten görünen varlıkları sürekli keşfetme, sahiplik ve riskle ilişkilendirme disiplini.

G103 — Internet-facing service: Doğrudan internetten erişilebilen uygulama, cihaz veya yönetim arabirimi; RaaS/IAB için yüksek öncelikli giriş yüzeyidir.

G104 — Vulnerability (zafiyet): Sistem, yazılım, yapılandırma veya süreçte kötüye kullanılabilecek zayıflık.

G105 — CVE: Kamuya açıklanmış siber güvenlik zafiyetlerine benzersiz kimlik veren Common Vulnerabilities and Exposures kaydı.

G106 — CVSS: Zafiyetin teknik şiddetini puanlayan sistem; aktif istismar, dışa açıklık ve iş etkisini tek başına göstermez.

G107 — KEV: CISA'nın gerçek dünyada istismar edildiği bilinen zafiyet kataloğu; RaaS yama önceliğinde güçlü sinyaldir.

G108 — Zero-day: Üretici veya savunmacının etkili düzeltme için sıfır günü olduğu, henüz yaması bulunmayabilen zafiyet/istismar durumu.

G109 — Exploit: Bir zafiyeti kullanarak beklenmeyen davranış veya yetkisiz erişim oluşturan kod/teknik; bu rehber uygulama ayrıntısı vermez.

G110 — Patch (yama): Yazılım hatası veya zafiyetini düzelten üretici güncellemesi.

G111 — Compensating control: Temel kontrol hemen uygulanamadığında riski geçici olarak azaltan segmentasyon, kapatma veya yoğun izleme gibi önlem.

G112 — End of Life (EOL): Ürünün üretici destek ve güvenlik güncellemesi döneminin sona ermesi.

G113 — Misconfiguration: Güvenli olmayan, gereksiz geniş veya varsayılan ayar nedeniyle oluşan risk.

G114 — Secure by default: Ürünün ilk kurulumda en güvenli makul ayarlarla gelmesi; müşterinin korumayı ayrıca açmasına ihtiyaç duymaması ilkesi.

G115 — Remote access: Kurum ağı veya hizmetine dış konumdan erişim; güçlü kimlik, cihaz ve oturum kontrolü gerektirir.

G116 — VPN: Uzak cihaz ile ağ arasında şifreli tünel kuran sanal özel ağ; kimlik ve cihaz güveni yoksa tek başına güvenli değildir.

G117 — RDP: Windows uzak masaüstü protokolü; internete doğrudan açılması ve zayıf kimlik doğrulama RaaS riskini artırır.

G118 — RMM: Uzak izleme ve yönetim platformu; meşru yönetim için güçlü, ele geçirilirse çok sayıda sisteme etki eden araçtır.

G119 — MSP: Müşteriler adına BT hizmeti yöneten sağlayıcı; erişim izolasyonu zayıfsa tedarik zinciri çarpanı olabilir.

G120 — Supply-chain compromise: Tedarikçi, yazılım, hizmet veya güncelleme güveninin hedefe erişmek için kötüye kullanılması.

G121 — Third-party risk: Tedarikçi ve alt yüklenicilerin kurumun hizmet, veri ve erişim güvenliğine eklediği risk.

G122 — Network segmentation: Ağı işlev ve güven düzeyine göre bölüp aradaki trafiği sınırlama.

G123 — Microsegmentation: Segmentasyonu iş yükü, uygulama veya kimlik düzeyinde daha ince politika hâline getirme.

G124 — East-west traffic: Kurum içi iş yükleri/segmentler arasındaki trafik; yatay hareket tespiti için önemlidir.

G125 — North-south traffic: Kurum ağı ile dış dünya/bulut/İnternet arasındaki giriş-çıkış trafiği.

G126 — Firewall: Ağ akışını kurallara göre izinleyen veya engelleyen kontrol; aşırı geniş kural segmentasyonu zayıflatır.

G127 — Allowlist: Yalnız açıkça onaylanmış uygulama, hedef veya işlemlere izin verme listesi.

G128 — Denylist: Bilinen kötü veya yasaklı öğeleri engelleyen liste; yeni/değişen tehditleri tek başına kapsamaz.

G129 — Egress filtering: Kurumdan dışarı giden bağlantı ve veri akışını iş gereksinimine göre sınırlama.

G130 — DNS logging: Alan adı çözümleme isteklerini kaydetme; nadir/kötü hedef ve olay zaman çizelgesi için görünürlük sağlar.

G131 — Proxy: İstemci ile dış hizmet arasında aracı olarak trafik politikası, kayıt ve filtreleme uygulayan sistem.

G132 — IDS: Şüpheli ağ/sistem etkinliğini tespit edip uyarı üreten saldırı tespit sistemi.

G133 — IPS: Şüpheli trafiği tespit yanında engellemeye çalışan saldırı önleme sistemi.

G134 — NDR: Ağ trafiği ve davranışından tehdit tespiti/yanıt sağlayan Network Detection and Response yaklaşımı.

G135 — Bastion host: Hassas ağa erişim için sıkılaştırılmış, izlenen aracı yönetim sistemi.

G136 — Jump server: Yönetici ile hedef sistem arasında kontrollü geçiş noktası; bastion güvenliğiyle uygulanmalıdır.

G137 — Privileged Access Workstation (PAW): Yalnız ayrıcalıklı yönetim için sıkılaştırılmış ve günlük kullanım/riskli webden ayrılmış cihaz.

G138 — Tier 0: Kimlik, güven ve yönetim alanını kontrol eden en kritik sistem/hesap sınıfı; ele geçirilmesi kurum çapında etki doğurur.

G139 — Active Directory: Windows etki alanlarında kimlik, cihaz ve politika yöneten dizin hizmeti; ransomware için yüksek değerli yönetim düzlemidir.

G140 — Microsoft Entra ID: Bulut kimlik ve erişim hizmeti; rol, uygulama izni ve oturum güvenliği RaaS savunmasında kritiktir.

G141 — Domain controller: Active Directory kimlik doğrulama ve dizin verisini sağlayan sunucu; ayrı koruma ve kurtarma sırası gerektirir.

G142 — Hypervisor: Bir fiziksel sistem üzerinde sanal makineleri yöneten katman; ele geçirilirse çok sayıda iş yükü aynı anda etkilenebilir.

G143 — Virtualization: İşlem, depolama veya ağı fiziksel donanımdan soyutlayarak sanal kaynak olarak işletme.

G144 — ESXi: VMware sanallaştırma hipervizörü; RaaS aktörlerinin yönetim düzlemi hedeflerinden biri olabilir.

G145 — Cloud control plane: Bulut kaynak, kimlik, ağ, anahtar ve politikalarını yöneten API/konsol katmanı.

G146 — SaaS: Uygulamanın sağlayıcı tarafından hizmet olarak sunulması; veri ve kimlik sorumluluğu yine müşteriyle paylaşılır.

G147 — IaaS: Sunucu, ağ ve depolama altyapısının bulut hizmeti olarak sunulması; müşteri işletim sistemi/kimlik güvenliğini yönetir.

G148 — Immutable infrastructure: Çalışan sistemi yerinde değiştirmek yerine güvenilir yeni imajla yeniden kurmayı hedefleyen altyapı yaklaşımı.

G149 — Operational Technology (OT): Fiziksel süreç, makine ve endüstriyel operasyonu izleyen/kontrol eden teknoloji.

G150 — IT/OT convergence: Kurumsal bilgi sistemleri ile operasyonel teknolojinin veri ve yönetim bağımlılıklarının artması; RaaS etkisini fiziksel sürece taşıyabilir.

D. Veri koruma, yedekleme ve kurtarma

G151 — Data classification: Veriyi hassasiyet, iş değeri ve hukuki gereksinime göre sınıflandırma.

G152 — Personal data (kişisel veri): Belirli veya belirlenebilir kişiyle ilişkili bilgi; sızıntısı bildirim ve mağdur riski doğurabilir.

G153 — Sensitive data: Açığa çıkması yüksek zarar yaratabilecek sağlık, kimlik, finans, güvenlik veya ticari bilgi.

G154 — Health data (sağlık verisi): Kişinin fiziksel/ruhsal sağlığı ve sağlık hizmetiyle ilgili yüksek hassasiyetli veri.

G155 — Intellectual property: Patent, tasarım, kaynak kod, formül, araştırma veya ticari sır gibi kurumun fikrî değeri.

G156 — Data minimization: Yalnız gerekli veriyi, gerekli süre ve kapsamda tutma; RaaS veri gaspı yüzeyini küçültür.

G157 — Retention (saklama): Verinin iş/hukuk gerekçesiyle ne kadar süre tutulacağı ve sonra güvenli silineceği kural.

G158 — DLP: Hassas verinin yetkisiz paylaşım, kopyalama veya dışarı çıkışını tespit/engelleyen Data Loss Prevention kontrolü.

G159 — DSPM: Bulut ve veri ortamlarında hassas veriyi keşfedip erişim, konum ve yanlış yapılandırma riskini yöneten yaklaşım.

G160 — Bulk export: Büyük miktarda verinin tek işlemle dışa aktarılması; meşru olabilir ama RaaS öncesi toplama sinyalidir.

G161 — Archive (arşiv): Verinin uzun süreli saklama veya aktarım için tek paket/düzenli yapıda toplanması.

G162 — Staging area: Veri dışa aktarımı veya işleme öncesi geçici toplama alanı; olağandışı büyüme erken uyarı olabilir.

G163 — Data lineage: Verinin kaynaktan hedefe nereden geldiğini, nasıl dönüştüğünü ve kimce kullanıldığını gösteren soy bilgisi.

G164 — Encryption at rest: Depolanan verinin anahtar olmadan okunamaması; RaaS şifrelemesinden farklı meşru gizlilik kontrolüdür.

G165 — Encryption in transit: Ağ üzerinden taşınan verinin dinlemeye karşı şifrelenmesi.

G166 — Key management: Kriptografik anahtarın üretim, saklama, erişim, döndürme, yedek ve imha yaşam döngüsü.

G167 — KMS: Anahtarları merkezi ve denetlenebilir biçimde yöneten Key Management Service.

G168 — Backup (yedek): Kaybolan/bozulan veriyi geri getirmek için tutulan ayrı kopya.

G169 — Full backup: Seçilen veri kümesinin tamamını içeren yedek.

G170 — Incremental backup: Son herhangi bir yedekten bu yana değişen veriyi alan yedek; geri dönüş zincir bağımlılığı taşır.

G171 — Differential backup: Son tam yedekten bu yana değişen veriyi alan yedek.

G172 — Snapshot: Belirli andaki depolama/sistem durumunu işaretleyen hızlı kopya; aynı yönetim alanındaysa bağımsız yedek değildir.

G173 — Replication: Verinin başka sisteme yakın gerçek zamanlı kopyalanması; bozulma/şifreleme de kopyalanabileceği için tek başına yedek değildir.

G174 — Sync (senkronizasyon): Dosya değişikliklerini konumlar arasında eşitleme; silme ve şifreleme de yayılabilir.

G175 — 3-2-1 backup: Üç kopya, iki farklı ortam ve bir tesis/ana sistem dışı kopya hedefleyen yedek stratejisi.

G176 — Immutable backup: Saklama süresi boyunca değiştirilemeyen/silinemeyen yedek kopya.

G177 — WORM: Verinin bir kez yazılıp çok kez okunabildiği, süre boyunca değiştirilemediği Write Once Read Many saklama ilkesi.

G178 — Object Lock: Nesne depolamada belirli süre silme/değiştirmeyi engelleyen teknik saklama özelliği.

G179 — Air gap: Üretim ile yedek arasında doğrudan sürekli ağ/yönetim bağlantısını kaldıran fiziksel veya mantıksal ayrım.

G180 — Offline backup: Normal operasyon sırasında ağa bağlı olmayan yedek.

G181 — Offsite backup: Ana tesis/hata alanından farklı yerde tutulan kopya.

G182 — Backup catalog: Hangi veri ve kurtarma noktalarının nerede bulunduğunu gösteren yedek indeksi; kendisi de korunmalıdır.

G183 — Retention lock: Saklama kuralının süre dolmadan kısaltılmasını veya kaldırılmasını engelleyen kilit.

G184 — Recovery point: Verinin geri döndürülebileceği belirli zaman/sürüm.

G185 — Clean room: Şüpheli üretim ortamından ayrılmış, geri yükleme ve incelemenin güvenli yapıldığı kontrollü ağ/altyapı.

G186 — Restore: Yedek veriyi hedef sisteme geri getirme işlemi.

G187 — Recovery: Veri, kimlik, uygulama ve iş hizmetini güvenli çalışır duruma döndürmenin restore'dan geniş süreci.

G188 — RPO: Kabul edilebilir azami veri kaybını zaman olarak ifade eden Recovery Point Objective.

G189 — RTO: Hizmetin kabul edilebilir sürede geri dönme hedefi olan Recovery Time Objective.

G190 — Maximum Tolerable Downtime (MTD): İşin ciddi/geri döndürülemez zarar görmeden dayanabileceği azami kesinti.

G191 — Backup integrity: Yedek verinin eksiksiz, bozulmamış ve beklenen sürüm olduğuna duyulan doğrulanmış güven.

G192 — Restore test: Yedekten seçili veya tam veriyi gerçekten geri getirip açılabilir/tutarlı olduğunu doğrulama.

G193 — Golden image: Güvenilir, yamalı ve yapılandırması doğrulanmış sistem kurulum şablonu.

G194 — Reimaging: Sistemi güvenilir imajdan yeniden kurarak şüpheli yazılım ve yapılandırmayı kaldırma.

G195 — Recovery key: Şifreli cihaz veya veriyi kurtarmak için kullanılan özel anahtar/kod; yedekten ayrı korunmalıdır.

G196 — Versioning: Dosyanın geçmiş sürümlerini saklayarak yanlış silme veya şifreleme öncesine dönüş sağlama.

G197 — Recovery vault: Yedek ve kurtarma noktalarını ayrı politika/kimlikle koruyan mantıksal kasa.

G198 — Cyber recovery: Kötü niyetli aktörün kimlik, yedek ve sistem bütünlüğünü hedeflediği senaryoya özel temiz kurtarma disiplini.

G199 — Recovery orchestration: Bağımlı sistemleri doğru sırayla ve otomasyon/denetimle geri getirme.

G200 — Data exfiltration: Verinin yetkisiz biçimde kurum dışına çıkarılması; yedek geri dönüşü bu gizlilik kaybını geri alamaz.

E. Tespit, müdahale ve adli süreç

G201 — EDR: Uç nokta/sunucuda davranış telemetrisi, tespit, araştırma, izolasyon ve yanıt sağlayan Endpoint Detection and Response.

G202 — XDR: Uç nokta, kimlik, e-posta, ağ ve bulut sinyallerini ortak olay bağlamında birleştiren Extended Detection and Response.

G203 — SIEM: Güvenlik günlüklarını merkezî toplayıp arama, korelasyon ve alarm sağlayan Security Information and Event Management.

G204 — SOAR: Güvenlik iş akışlarını araçlar arasında onaylı biçimde otomatikleştiren Security Orchestration, Automation and Response.

G205 — SOC: Güvenlik olaylarını izleyen, araştıran ve müdahaleyi koordine eden Security Operations Center.

G206 — Telemetry (telemetri): Sistem, kimlik, ağ ve uygulama davranışını anlamak için üretilen gözlem verisi.

G207 — Log (günlük): Bir sistemde gerçekleşen olay, erişim veya değişikliği zaman ve bağlamla kaydeden veri.

G208 — Audit log: Özellikle kim/ne zaman/ne yaptı sorusunu yanıtlamak için tutulan denetim günlüğü.

G209 — Log source health: Günlük kaynağının veri gönderip göndermediği, zamanı ve alanlarının doğru olup olmadığı durumu.

G210 — Time synchronization: Sistem saatlerinin ortak güvenilir zamana eşitlenmesi; olay korelasyonu ve delil için gereklidir.

G211 — NTP: Sistem saatlerini ağ üzerinden eşitlemek için kullanılan Network Time Protocol.

G212 — Baseline (taban çizgisi): Kullanıcı, cihaz veya uygulamanın normal davranış aralığı; anomaliyi bağlamlandırır.

G213 — Anomaly (anomali): Beklenen taban çizgisinden anlamlı sapma; kötü niyet kanıtı değil araştırma sinyalidir.

G214 — Correlation rule: Birden çok olay ve kaynağı zaman/kimlik/varlık ilişkisiyle birleştirip alarm üreten kural.

G215 — Detection engineering: Tehdit davranışını güvenilir veri, kural, test ve geri bildirimle sürdürülebilir tespitte dönüştürme disiplini.

G216 — Threat hunting: Mevcut alarmların kaçırdığı olası kötü davranışı hipotez ve telemetriyle proaktif arama.

G217 — Hunting hypothesis: Belirli tehdit davranışının ortamda gerçekleşmiş olabileceğine dair test edilebilir savunma varsayımı.

G218 — Forensic image: Depolama ortamının adli bütünlük korunarak alınan bit düzeyi veya mantıksal kopyası.

G219 — Memory capture: Çalışan sistemin RAM içeriğini olay analizi için toplama; uçucu kanıtı korur.

G220 — Chain of custody: Delilin kim tarafından ne zaman toplandığı, taşındığı, işlendiği ve korunduğu kayıt zinciri.

G221 — Evidence preservation: Olay kanıtını değişiklik, silinme, yetkisiz erişim ve gereksiz ifşadan koruma.

G222 — Containment: Saldırganın yayılmasını ve zararı sınırlamak için erişim, cihaz veya ağı kontrollü kısıtlama.

G223 — Eradication: Yetkisiz kalıcılık, kötü yazılım, ele geçirilmiş kimlik ve kök nedeni ortamdan kaldırma.

G224 — Remediation: Zafiyet, yanlış yapılandırma veya süreç açığını düzelterek tekrar riskini azaltma.

G225 — Isolation: Şüpheli cihaz, hesap veya segmentin diğer kaynaklarla iletişimini kontrollü kesme.

G226 — Quarantine: Şüpheli dosya veya sistemi analiz/karar için kısıtlı alanda tutma.

G227 — Indicator blocking: Bilinen kötü hash, alan, IP veya hesabı güvenlik katmanlarında engelleme; davranış tespitini tamamlar.

G228 — IOC sweep: Belirli göstergelerin kurum telemetri ve varlıklarında aranması.

G229 — Retro hunt: Yeni elde edilen gösterge veya davranışı geçmiş telemetride geriye dönük arama.

G230 — Case management: Olay bulgusu, kanıt, görev, karar ve iletişimin tek kayıt altında yönetilmesi.

G231 — Severity (önem seviyesi): Olayın iş, veri, yayılma ve insan güvenliği etkisine göre öncelik sınıfı.

G232 — Triage: Alarm veya olayı hızla doğrulayıp kapsam, önem ve sonraki eylemi belirleme.

G233 — False positive: Alarmın kötü niyetli olay göstermediği hâlde tetiklenmesi.

G234 — False negative: Gerçek kötü etkinliğin tespit sistemi tarafından kaçırılması.

G235 — MTTD: Mean Time to Detect; kötü etkinliğin başlaması ile tespit arasındaki ortalama süre.

G236 — MTTR: Bağlama göre Mean Time to Respond/Recover; ölçüm tanımı açıkça belirtilmelidir.

G237 — MTTC: Mean Time to Contain; olayın tespitinden etkili kontrol altına almaya kadar geçen ortalama süre.

G238 — Playbook: Belirli olay senaryosunda karar, rol ve eylem adımlarını tanımlayan müdahale planı.

G239 — Runbook: Belirli teknik/operasyonel görevin ayrıntılı, tekrarlanabilir yürütme talimatı; erişimi ve içeriği korunmalıdır.

G240 — Incident commander: Olay önceliği, yetki, iletişim ritmi ve karar günlüğünden sorumlu komuta rolü.

G241 — Crisis management: Teknik olayın hizmet, insan, hukuk, finans ve kamuoyu etkisini üst düzeyde koordine etme.

G242 — Communications plan: Çalışan, müşteri, düzenleyici, medya ve tedarikçiye kim, ne zaman, hangi kanıtla bilgi vereceğini tanımlayan plan.

G243 — Legal hold: İlgili kayıt ve verilerin normal silme döngüsünden çıkarılıp hukuki süreç için korunması talimatı.

G244 — Breach notification: Veri ihlalinin yasa, sözleşme veya düzenleyici gereğince yetkili kurum ve kişilere bildirilmesi.

G245 — Tabletop exercise: Katılımcıların senaryo üzerinden karar ve koordinasyonu masa başında test ettiği tatbikat.

G246 — Purple team: Saldırı simülasyonu ve savunma ekiplerinin tespit/önleme geliştirmek için iş birliği yaptığı çalışma biçimi.

G247 — Red team: Yetkili ve kontrollü biçimde gerçekçi saldırgan davranışı simüle eden ekip; kapsam ve güvenlik kurallarıyla çalışır.

G248 — Blue team: Kurum sistemlerini izleyen, savunan, tespit ve müdahale eden ekip.

G249 — Post-incident review: Olay zaman çizelgesi, karar ve kontrol başarısızlığını suçlamadan analiz eden ders çıkarma süreci.

G250 — Root cause: Olayın gerçekleşmesine olanak veren temel teknik/süreç nedeni; tek kullanıcı hatasına indirgenmemelidir.

F. Dayanıklılık, ekonomi, yönetişim ve kanıt

G251 — Contributing factor: Kök neden olmasa da olayın olasılık veya etkisini artıran ek koşul.

G252 — Lessons learned: Olay veya tatbikattan çıkarılan ve sahip/tarih/doğrulamayla iyileştirmeye dönüştürülen dersler.

G253 — Business Continuity Plan (BCP): Teknoloji tamamen dönmeden kritik hizmeti güvenli asgari kapasitede sürdürme planı.

G254 — Disaster Recovery Plan (DRP): Teknoloji ve veriyi belirlenen RTO/RPO ile güvenli biçimde geri getirme planı.

G255 — Business Impact Analysis (BIA): Hizmet kesintisinin zamanla finans, insan, hukuk ve operasyon üzerindeki etkisini analiz etme.

G256 — Critical service: Kesintisi insan güvenliği, kamu, yasal yükümlülük veya kurum varlığı üzerinde kabul edilemez etki yaratan hizmet.

G257 — Dependency mapping: Hizmetin kimlik, DNS, ağ, veri, tedarikçi, insan ve tesis bağımlılıklarını gösterme.

G258 — Single point of failure: Arızası/ihlali tek başına hizmeti durduran, yedeği veya alternatifi olmayan bileşen.

G259 — Concentration risk: Çok sayıda hizmet/kurumun aynı sağlayıcı, platform veya kimlik alanına bağımlı olması riski.

G260 — Degraded mode: Tam işlev yerine güvenli ve sınırlı kapasiteyle hizmeti sürdürme durumu.

G261 — Manual workaround: Dijital sistem yokken işlemi kontrollü kâğıt/telefon/alternatif yöntemle yürütme; sonradan mutabakat gerekir.

G262 — Mutual aid: Kurumların kriz sırasında kapasite, laboratuvar, altyapı veya personel desteğini önceden anlaşmayla paylaşması.

G263 — Cyber insurance: Belirli siber olay maliyetlerini şart ve limitlerle karşılayan sigorta; temel kontrol ve hukuki yükümlülüğün yerine geçmez.

G264 — Ransom payment: Suç aktörüne erişim/veri vaadi karşılığında yapılan ödeme; kurtarma, silme veya tekrar saldırmama garantisi vermez.

G265 — Sanctions risk: Ödemenin yaptırım altındaki kişi/kurumla ilişki nedeniyle hukuki risk doğurması.

G266 — Cryptocurrency: Kriptografik ağlarda temsil edilen dijital varlık; ransomware ödemelerinde kullanılabilir, mutlaka anonim değildir.

G267 — Bitcoin: Kamuya açık blokzincire dayalı kripto varlık; işlem izleri kolluk/adli analizde kullanılabilir.

G268 — Blockchain: İşlemlerin dağıtık ve zincirlenmiş kayıt yapısında tutulduğu defter teknolojisi.

G269 — Wallet (cüzdan): Kripto varlık anahtar ve adreslerini yöneten araç/hesap; adres gerçek kişi kimliğini tek başına göstermez.

G270 — Mixer/tumbler: Kripto işlem izini karmaşıklaştırmaya çalışan hizmet; kullanımı hukuki/yaptırım riski taşır ve bu rehber operasyonel ayrıntı vermez.

G271 — Transaction tracing: Blokzincir üzerindeki işlem ilişkilerini yöntem ve ek kanıtla analiz etme.

G272 — Law enforcement: Suç soruşturma, delil toplama, altyapı bozma ve varlık kurtarma yetkili kolluk kurumları.

G273 — CERT/CSIRT: Siber olay bildirim, koordinasyon, teknik destek ve bilgi paylaşımı yapan müdahale ekibi.

G274 — Responsible disclosure: Zafiyet veya olayı etkilenen taraf ve yetkili kanallarla zararı azaltacak biçimde bildirme.

G275 — Materiality: Olayın yatırımcı/kurum kararı açısından önemli olup olmadığını belirleyen hukuki ve finansal değerlendirme.

G276 — Board oversight: Yönetim kurulunun siber riski, kritik hizmeti, kaynak ve kalan riski gözetme sorumluluğu.

G277 — Risk appetite: Kurumun hedefleri uğruna kabul etmeye istekli olduğu genel risk düzeyi.

G278 — Risk tolerance: Belirli ölçüt veya hizmet için kabul edilen sapma/sınır.

G279 — Risk acceptance: Belirli kalan riskin yetkili yönetimce kanıt ve süreyle kabul edilmesi.

G280 — Residual risk: Kontroller uygulandıktan sonra kalan risk.

G281 — Inherent risk: Kontroller dikkate alınmadan önceki doğal risk düzeyi.

G282 — Security control: Riski önleme, tespit, müdahale veya kurtarmayla azaltan teknik, idari ya da fiziksel önlem.

G283 — Defense in depth: Bir kontrol başarısız olduğunda diğerinin etkiyi sınırlaması için katmanlı savunma kurma.

G284 — Zero Trust: Ağ konumuna kalıcı güven vermeden her kaynak erişimini kimlik, cihaz ve bağlamla değerlendiren mimari yaklaşım.

G285 — NIST CSF 2.0: Siber risk yönetimini Govern, Identify, Protect, Detect, Respond ve Recover işlevlerinde düzenleyen çerçeve.

G286 — Govern: CSF 2.0'da siber risk stratejisi, politika, rol ve tedarik zinciri yönetişimi işlevi.

G287 — Identify: Varlık, risk, iyileştirme ve bağımlılıkları anlama işlevi.

G288 — Protect: Kimlik, veri, platform, farkındalık ve dayanıklılık kontrollerini uygulama işlevi.

G289 — Detect: Anomali, olay ve tehdit davranışını zamanında bulma işlevi.

G290 — Respond: Olayı yönetme, analiz, iletişim ve etkiyi azaltma işlevi.

G291 — Recover: Hizmet ve varlıkları güvenli biçimde geri getirme ve iyileştirme işlevi.

G292 — MITRE ATT&CK: Gerçek dünyada gözlenen saldırgan taktik/tekniklerini sınıflandıran savunma bilgi tabanı.

G293 — ATT&CK tactic: Saldırganın yüksek düzeyli amacı; örneğin ilk erişim, keşif veya etki.

G294 — ATT&CK technique: Bir taktik amacı gerçekleştirmek için gözlenen genel davranış yöntemi.

G295 — ATT&CK sub-technique: Bir tekniğin daha özel davranış alt sınıfı.

G296 — Confidence level: Atıf veya bulgunun kanıt gücünü düşük/orta/yüksek gibi ölçülü dille ifade etme.

G297 — Primary source: Olayı doğrudan yaşayan, soruşturan, düzenleyen veya resmî kayda alan kurumun kaynağı.

G298 — Evidence grading: Kaynağı ve iddiayı güven, bağımsızlık ve yöntemine göre derecelendirme.

G299 — Cyber resilience: Saldırıyı önleme yanında etki sırasında hizmeti sürdürme, güvenli kurtarma ve uyum sağlama kapasitesi.

G300 — Ransomware-resistant backup: Saldırganın silme, değiştirme ve yönetim ele geçirmesine karşı ayrı kimlik, saklama kilidi ve testle korunan yedek.

RaaS açısından neden önemli?

RaaS ekosistemi ekonomi, kimlik, ağ, veri, yedek, tespit ve kriz terimlerini aynı olayda birleştirir. Bu 300 terim, ekiplerin aynı kavrama aynı anlamı vermesini sağlayarak yanlış atıf, eksik kapsam ve geç karar riskini azaltır.

RaaS Hakkında Sık Sorulan Sorular

Bu bölüm 150 soruya kısa fakat karar verilebilir yanıt verir. Yanıtlar hukuk veya olay müdahale danışmanlığının yerine geçmez; kurumun ülke, sektör ve sözleşme koşulları ayrıca değerlendirilmelidir.

A. Temel kavramlar

SSS001 — RaaS ile ransomware aynı şey midir? Hayır. Ransomware zararlı yazılım/operasyon sınıfıdır; RaaS bunun operatör tarafından bağlı kuruluşlara hizmet olarak sunulduğu ekonomik ve örgütsel modeldir.

SSS002 — Bir olayın RaaS olduğunu nasıl anlarız? Operatör–affiliate ayrımı, gelir paylaşımı, ortak panel/yayın altyapısı veya resmî kurum değerlendirmesi aranır. Yalnız fidye notundaki marka, modeli kesin doğrulamaz.

SSS003 — RaaS sadece dosya şifreler mi? Hayır. Modern olaylar veri hırsızlığı, yayın tehdidi, müşteri baskısı ve hizmet kesintisini birleştirebilir; bazıları şifreleme yapmaz. S01 S13

SSS004 — RaaS yasal SaaS ile gerçekten aynı mı? Yalnız tekrarlanabilir hizmet, panel ve gelir modeli benzetmesi vardır. RaaS hukuka aykırı, zorlamaya dayalı ve tarafların birbirine güvenmediği suç ekosistemidir.

SSS005 — Küçük kurum RaaS hedefi olur mu? Evet. Zayıf erişim, kritik yerel hizmet veya hassas veri varsa saldırgan için kârlı olabilir; fırsatçı tarama kurum büyüklüğünü önemsemeyebilir.

SSS006 — Ev kullanıcısı RaaS hedefi midir? RaaS programları çoğunlukla kurumsal gasp peşindedir, fakat ev cihazları kimlik/erişim çalmak, botnet veya dolandırıcılık için etkilenebilir. Temel yedek, güncelleme ve MFA yine gereklidir.

SSS007 — RaaS saldırısı mutlaka fidye notu bırakır mı? Hayır. Veri hırsızlığı odaklı olayda temas e-posta/telefonla gelebilir veya kurum saldırıyı sızıntı iddiasından öğrenebilir.

SSS008 — Şifre çözücü varsa olay çözülmüş olur mu? Hayır. Şifre çözücü yavaş/eksik çalışabilir; veri sızıntısı, kalıcılık, kimlik ihlali ve yasal bildirim sorunlarını çözmez.

SSS009 — RaaS bir siber savaş aracı mıdır? Temel motivasyon genellikle finansaldır; fakat devlet etkisi, ideoloji veya yıkıcı operasyonla sınırlar karışabilir. Atıf ve amaç olay bazında kanıtlanmalıdır.

SSS010 — Bu rehberin saldırı akışını anlatması riskli değil mi? Akış yalnız amaç, tespit ve engelleme düzeyindedir. Çalışır komut, zararlı kod, istismar zinciri, canlı site veya ödeme gizleme yöntemi verilmez.

B. Tarih ve ekosistem

SSS011 — İlk ransomware hangisiydi? 1989 AIDS/PC Cyborg olayı tarihsel literatürde ilk belgelenen örneklerden sayılır. Bu, RaaS değildi; hizmet modeli daha sonra gelişti. S63

SSS012 — İlk RaaS hangisiydi? Kesin ve tartışmasız bir “ilk” yoktur. Tox ve Cerber 2015–2016 döneminin erken örnekleri olarak sık anılır, fakat yeraltı kayıtları ve tanım farkı nedeniyle dikkatli dil gerekir.

SSS013 — CryptoLocker neden dönüm noktasıdır? Güçlü şifreleme, otomatik dağıtım ve kripto ödemeyi geniş ölçekte birleştirdi; 2014 çok uluslu bozma operasyonu küresel müdahalenin önemini gösterdi. S24

SSS014 — Çift gasp ne zaman yaygınlaştı? 2019 civarında Maze ile ilişkilendirilen veri yayımlama baskısı görünür bir dönüm noktası oldu; 2020'lerde RaaS operasyonlarında yaygınlaştı.

SSS015 — Neden marka kapanınca tehdit bitmiyor? Kod, erişim, bağlı kuruluş ve uzmanlık başka markalara taşınabilir. NCSC, LockBit bozması sonrası ekosistemin çeşitlenerek yüksek tehdit olmaya devam ettiğini belirtti. S11

SSS016 — RaaS programı affiliate'i nasıl seçer? Yeraltı programları itibar, geçmiş kazanç ve erişim kanıtı arayabilir; süreçler doğrulanamaz suç pazarlamasına dayanabilir. Savunma açısından sonuç, aynı marka altında farklı operasyon kalitesi beklemektir.

SSS017 — IAB neden RaaS için önemlidir? RaaS bağlı kuruluşunun ilk erişimi kendisinin üretmesi gerekmez. IAB erişimi ticari mala dönüştürür ve ilk ihlal ile ransomware etkisi arasında aktör/zaman ayrımı yaratır.

SSS018 — Veri sızıntısı sitesi ne işe yarar? Mağdur adı veya veri örneğini yayımlayarak ödeme baskısı kurar. Listedeki her ad doğrulanmış şifreleme veya veri ihlali değildir.

SSS019 — Sızıntı sitesi sayıları neden farklıdır? Kaynaklar farklı markaları, tarih aralıklarını, tekrarları ve doğrulama ölçütlerini kullanır. Yayın tarihi olay tarihi değildir ve ödeme yapanlar listeden çıkarılabilir.

SSS020 — Kripto para RaaS'ı tamamen anonim yapar mı? Hayır. Kamuya açık zincir işlem izi bırakır; Colonial ödemesinin bir kısmı DOJ tarafından ele geçirildi. Kimlik atfı yine ek kanıt gerektirir. S41

C. Gruplar ve atıf

SSS021 — Bir grup saldırıyı üstlenirse inanmalı mıyız? Üstlenme bir iddiadır. Mağdur bildirimi, kolluk atfı, adli kanıt ve bağımsız olay müdahale verisiyle doğrulanmalıdır.

SSS022 — LockBit 2024'te kapatılmadı mı? Altyapısı ciddi biçimde bozuldu; ancak marka ve bazı faaliyetler parçalı biçimde geri döndü. Bozma başarısı tehdidin tamamının sona erdiği anlamına gelmez. S11 S28

SSS023 — Conti hâlâ aktif mi? Ana marka 2022'de kapandı. Eski aktör ve yöntemlerin başka yapılara dağıldığı değerlendirilir; güncel her benzer olaya “Conti” demek doğru değildir.

SSS024 — REvil'in en bilinen olayları hangileridir? FBI'nın atfettiği JBS ve DOJ kayıtlarındaki Kaseya VSA olayı öne çıkar. S42 S45

SSS025 — ALPHV/BlackCat aktif mi? 2023 bozma ve 2024 çöküş/çıkış sonrası marka aktif kabul edilmez. Eski bağlı kuruluşların başka gruplara geçmesi riskin sürdüğü anlamına gelir.

SSS026 — Cl0p neden klasik ransomware'dan farklı görünüyor? MOVEit gibi kampanyalarda şifreleme yerine kitlesel veri hırsızlığı ve gasp öne çıktı. Bu, RaaS bağlantılı olay planının data-extortion senaryosunu kapsaması gerektiğini gösterir. S31

SSS027 — Akira neden güncel risk sayılıyor? FBI 2025 şikâyetlerinde en görünür varyantlar arasında yer aldı; resmî ortak uyarı çoklu sektör ve platform etkisini belgeledi. S10 S32

SSS028 — Play gerçekten RaaS mı? Bazı kaynaklar kapalı grup/ortaklık olarak tanımlar; klasik herkese açık affiliate programı olduğu kesin değildir. Yine de geniş ransomware faaliyeti ve yaklaşık 900 bilinen etkilenen kuruluş resmî uyarıda yer alır. S34

SSS029 — DragonForce “kartel” mi? Marka kendini ve iştirak ilişkilerini kartel diye pazarlayabilir; bu tek komuta kanıtı değildir. CCB 2026 onu büyüyen RaaS operatörü olarak değerlendirir. S36

SSS030 — Aynı aktör neden farklı isimlerle anılır? Yazılım, grup, sızıntı sitesi, araştırmacı kod adı ve yargı kimliği farklı olabilir. Eş adlar kanıt ve tarih bağlamıyla açıklanmalıdır.

D. İlk erişim ve operasyon akışı

SSS031 — En sık ilk erişim yolu nedir? Tek evrensel yol yoktur; geçerli hesap, internetten açık zayıf hizmet, sosyal mühendislik ve üçüncü taraf erişimi sık kategorilerdir. Kurum kendi telemetrisini esas almalıdır.

SSS032 — Ransomware ne kadar süre gizli kalabilir? Dakikalardan aylara değişebilir. IAB erişimi satılabilir veya saldırgan veri/ayrıcalık için bekleyebilir; bu yüzden günlük saklama yalnız birkaç gün olmamalıdır.

SSS033 — Şifreleme saldırının ilk adımı mı? Genellikle hayır. Erişim, yetki, keşif, veri toplama ve yedek müdahalesi daha önce olabilir.

SSS034 — RaaS saldırganı neden Active Directory'yi hedefler? Kimlik ve politika merkezi olduğundan geniş erişim, dağıtım ve güvenlik kontrolü sağlayabilir. Bu yüzden ayrıcalıklı dizin yönetimi Tier-0 olarak korunur.

SSS035 — Neden hipervizörler hedef oluyor? Tek yönetim düzlemi çok sayıda sanal iş yükünü etkileyebilir. Olay müdahale araştırmaları 2025'te sanallaştırma hedeflemesinin belirgin olduğunu bildirdi. S13

SSS036 — RMM aracı neden risklidir? Meşru olarak çok sayıda uç noktada yönetim yetkisi taşır. Ele geçirilirse güvenilir dağıtım kanalı saldırı çarpanına dönüşebilir.

SSS037 — Veri sızdırma şifrelemeden önce mi olur? Sıklıkla önce veya paralel yürür; fakat her olay farklıdır. Büyük arşiv ve dış veri akışı erken uyarı olabilir.

SSS038 — Saldırgan yedekleri neden hedefler? Kurumun ödeme yapmadan geri dönme seçeneğini azaltmak için. Yedek hesabı ve saklama kilidi üretimden ayrılmalıdır.

SSS039 — Ağ içinde yayılma nasıl engellenir? Segmentasyon, ayrı yönetim ağı, PAM, benzersiz yerel yönetici ve en az yetki birlikte kullanılır. Tek güvenlik duvarı kuralı yeterli değildir.

SSS040 — RaaS operasyonları her zaman aynı sırayı mı izler? Hayır. Aşamalar atlanabilir, paralel yürüyebilir veya farklı aktörlere devredilebilir; kavramsal akış savunma planıdır, reçete değildir.

E. Erken uyarı ve tespit

SSS041 — En erken kullanıcı işareti nedir? Başlatılmayan MFA/parola sıfırlama, bilinmeyen destek teması veya posta kuralı erken işaret olabilir. Tek başına kanıt değildir ama hızlı bildirilmelidir.

SSS042 — Fidye notu görülürse ilk ne yapılmalı? Notu silmeyin veya yanıtlamayın; olay kanalını çağırın, cihazı prosedüre göre izole edin ve delili koruyun.

SSS043 — Çok sayıda dosya uzantısı değişmesi kesin ransomware mıdır? Güçlü işarettir fakat meşru toplu işlem de olabilir. Kaynak hesap, süreç, hız ve diğer sistem etkisiyle doğrulanmalıdır.

SSS044 — EDR alarmı yoksa sistem temiz midir? Hayır. Ajan çalışmıyor, kapsam dışı veya davranış başka katmanda olabilir. “Telemetri yok” temiz değil bilinmiyor demektir.

SSS045 — Yüksek dış trafik her zaman veri sızıntısı mıdır? Hayır. Yedek, video veya meşru aktarım olabilir; hassas kaynak erişimi, kullanıcı, hedef ve zamanla ilişkilendirilmelidir.

SSS046 — Günlük kaynağının susması neden alarmdır? Saldırgan günlüklemeyi durdurmuş veya ajanı bozmuş olabilir. Teknik arıza da mümkündür; her iki durumda görünürlük kaybı acilen doğrulanır.

SSS047 — Hangi loglar en önemlidir? Kimlik/MFA, EDR, dizin, DNS/proxy, bulut, e-posta, yedek, hipervizör ve kritik uygulama günlükleri RaaS zincirini birlikte gösterir.

SSS048 — IOC listesi yeterli midir? Hayır. IP, alan ve hash hızla değişebilir; davranış, kimlik ve yönetim düzlemi tespitleri gerekir.

SSS049 — Yanlış pozitif çoksa alarm kapatılmalı mı? Alarm bağlam, varlık kritiklik ve meşru örneklerle ayarlanmalıdır. Tamamen kapatmak yerine kuralın veri ve eşik kalitesi düzeltilir.

SSS050 — Tehdit avcılığı ile SIEM aynı mı? Hayır. SIEM veri/korelasyon platformudur; tehdit avcılığı hipotezle proaktif arama sürecidir ve SIEM/XDR/EDR verisini kullanabilir.

F. Kimlik güvenliği

SSS051 — SMS MFA hiç kullanmamak mı daha iyi? Hayır; MFA'sızlıktan genellikle iyidir. Fakat phishing-resistant passkey/FIDO2 daha güçlüdür ve kritik hesaplarda önceliklendirilmelidir. S17

SSS052 — MFA varken hesap nasıl ele geçirilir? Onay yorgunluğu, faktör sıfırlama, eski protokol, token/çerez hırsızlığı veya kötü niyetli uygulama izni MFA'yı çevreleyebilir.

SSS053 — Parola değişikliği olayda yeterli mi? Hayır. Aktif oturum, refresh token, cihaz kaydı, uygulama parolası, OAuth izni ve posta kuralı da incelenip iptal edilmelidir.

SSS054 — Passkey ransomware'ı bitirir mi? Hayır. İlk erişim riskini önemli azaltır; zafiyet, kötü cihaz, tedarikçi ve ayrıcalık hatalarını çözmez.

SSS055 — Servis hesaplarına MFA nasıl uygulanır? İnsan MFA'sı yerine iş yükü kimliği, kısa ömürlü sertifika/token, kasa ve ağ/işlem sınırı kullanılır. Etkileşimli oturum kapatılır.

SSS056 — Break-glass hesap neden gerekir? Kimlik hizmeti arızasında acil yönetim erişimi sağlar. Çevrimdışı/çift kontrollü korunmalı ve her kullanımı kritik alarm üretmelidir.

SSS057 — Ortak yönetici hesabı neden tehlikelidir? Kimin işlem yaptığı belirlenemez, parola geniş paylaşılır ve tek ihlal çok kişiye/servise etki eder.

SSS058 — Yardım masası güvenliği neden Tier-0 sayılır? Faktör ve parola sıfırlayarak en güçlü kimlik kontrolünü atlayabilir. Kimlik kanıtı, çift onay ve bağımsız alarm gerekir.

SSS059 — Eski çalışan hesabı hemen silinmeli mi? Erişim derhâl kapatılmalı; veri/posta saklama hukuk ve iş gereksinimiyle ayrı yönetilmelidir. Hesabı aktif bırakmak arşiv yöntemi değildir.

SSS060 — Koşullu erişim yeterli midir? Güçlü bir katmandır; yanlış istisna, yönetilmeyen cihaz veya IdP ihlaliyle aşılabilir. Politika, günlük, cihaz ve PAM birlikte gerekir.

G. Uç nokta, ağ ve bulut

SSS061 — Antivirüs ile EDR arasındaki fark nedir? Antivirüs bilinen zararlı ve temel davranışı engeller; EDR daha geniş telemetri, araştırma, zaman çizelgesi ve izolasyon sağlar.

SSS062 — EDR tüm sunuculara kurulmalı mı? Desteklenen kritik sunucu ve iş yüklerinde evet; performans/uyumluluk test edilir. Kurulamayan sistem telafi edici ağ/uygulama izleme ve segmentasyonla korunur.

SSS063 — XDR zorunlu mu? Ürün adı zorunlu değildir; kimlik, uç nokta, e-posta, ağ ve bulut sinyallerini ortak olayda birleştirme yeteneği gereklidir.

SSS064 — Düz ağın sorunu nedir? Ele geçirilmiş cihazın çok sayıda sunucu ve yönetim hizmetine ulaşmasını kolaylaştırır; etki yarıçapını büyütür.

SSS065 — Mikrosegmentasyon sıfır risk sağlar mı? Hayır. Yanlış kural, ortak kimlik ve uygulama bağımlılığı riski sürer. Kritik akıştan başlayıp ölçülü uygulanmalıdır. S19

SSS066 — VPN güvenli erişim demek midir? Şifreli tünel sağlar; çalınmış hesap veya güvensiz cihazı meşrulaştırmaz. MFA, cihaz güveni ve en az yetki gerekir.

SSS067 — Bulutta ransomware olur mu? Evet. Kimlik ve kontrol düzlemi ele geçirilirse bulut veri, yedek, politika ve sanal kaynaklar şifrelenebilir/silinebilir. S14

SSS068 — SaaS verisini sağlayıcı zaten yedeklemiyor mu? Sağlayıcının süreklilik kopyası müşterinin ayrıntılı kurtarma, saklama ve ihlal gereksinimini karşılamayabilir. Sorumluluk ve geri dönüş yeteneği sözleşmede/testte doğrulanır.

SSS069 — IoT cihazı RaaS için önemli mi? Doğrudan şifreleme hedefi olmasa da zayıf cihaz ağda erişim ve görünürlük boşluğu yaratabilir. Ayrı ağ ve güncel firmware gerekir.

SSS070 — OT'yi internetten ayırmak yeterli mi? Hayır. Vendor erişimi, mühendislik cihazı, veri akışı ve BT bağımlılığı köprü olabilir. BT–OT güven yolları belgelenip test edilir.

H. Veri ve yedekleme

SSS071 — Bulut senkronizasyonu yedek midir? Tek başına değil. Şifrelenmiş/silinmiş dosyayı da eşitleyebilir; sürümleme ve bağımsız kopya gerekir.

SSS072 — Snapshot yedek sayılır mı? Aynı yönetim ve depolama hata alanındaysa bağımsız yedek değildir. Hızlı geri dönüş katmanıdır, 3-2-1 ve immutable kopyayı tamamlar.

SSS073 — Immutable yedek gerçekten silinemez mi? Doğru kilit ve süre içinde silinmemelidir; yanlış yapılandırma, hesap/anahtar kaybı ve bozuk veri riski sürer.

SSS074 — Air gap fiziksel olmak zorunda mı? Hayır; güçlü mantıksal/kimlik ayrımı da kullanılabilir. Ama aynı yönetici ve sürekli erişim varsa gerçek ayrım zayıftır.

SSS075 — Yedek ne sıklıkla test edilmeli? Kritiklik ve değişim hızına göre; örnek geri yükleme sık, uçtan uca hizmet kurtarma düzenli ve değişiklik sonrası yapılmalıdır. Takvimden çok ölçülmüş RTO/RPO önemlidir.

SSS076 — Yedek hesabı neden ayrı olmalı? Üretim dizini ele geçirilse bile saldırganın yedek silme yetkisine ulaşmamasını sağlar. Ayrı hesap/kimlik, güçlü MFA ve ikinci onay gerekir.

SSS077 — En son yedek her zaman en iyi kurtarma noktası mı? Hayır. Saldırgan uzun süre içerideyse son kopya kalıcılık, bozuk veri veya zayıf yapılandırma içerebilir; birden çok tarih korunur.

SSS078 — Şifreli yedek ile ransomware şifrelemesi aynı mı? Hayır. Meşru yedek şifrelemesi gizlilik için anahtar yönetimiyle yapılır; ransomware erişilebilirliği bozmak için yetkisizdir.

SSS079 — Veri minimizasyonu RaaS'a nasıl yardım eder? Gereksiz veri tutulmazsa saldırganın çalabileceği ve yayın tehdidinde kullanabileceği kapsam küçülür.

SSS080 — DLP veri sızıntısını tamamen engeller mi? Hayır. Yanlış politika, şifreli kanal ve meşru bulut kötüye kullanımı görülebilir. DLP; sınıflandırma, kimlik, egress ve insan analiziyle çalışır.

I. Olay müdahalesi

SSS081 — Şüpheli cihaz kapatılmalı mı? Genellikle ağ izolasyonu uçucu delili korur; aktif yaygın şifrelemede hızlı kapatma gerekebilir. Klinik/OT etkisi ve prosedür dikkate alınır.

SSS082 — Tüm ağı hemen kapatmak doğru mu? Kör biçimde değil. Yayılmayı sınırlar ama kritik hizmet ve delili de yok edebilir; segment, kimlik ve yönetim düzlemi risk bazlı izole edilir.

SSS083 — İlk aranacak kişi kimdir? Önceden atanmış olay komutanı/SOC ve kurum içi acil kanal. Kritik olayda hukuk, operasyon, iletişim ve üst yönetim hızla dâhil edilir.

SSS084 — Kolluk ne zaman aranmalı? Yerel hukuk ve prosedüre göre mümkün olduğunca erken; aktif tehdit, kritik hizmet, ödeme talebi veya büyük veri etkisi varsa geciktirilmemelidir.

SSS085 — Sigorta şirketi ne zaman bildirilir? Poliçedeki süre ve onay şartına göre erken. Sigorta, kolluk/hukuk ve teknik müdahale sorumluluğunun yerine geçmez.

SSS086 — Fidye notu delil midir? Evet, olay kaydıdır; fakat fail ve veri kapsamını tek başına doğrulamaz. Silinmeden güvenli biçimde korunur.

SSS087 — Parolaları hemen topluca değiştirelim mi? Güvenilir yönetim kanalı olmadan kitlesel değişim hizmeti kilitleyebilir ve saldırganı uyarabilir. Önce ele geçirilmiş hesap/oturumlar, sonra risk sıralı sır yenileme yapılır.

SSS088 — Yedekten ne zaman dönülür? Kök neden, güvenilir kurtarma noktası, temiz oda ve temel kimlik/ağ güveni yeterince doğrulanınca. Acele geri dönüş yeniden enfeksiyon riski taşır.

SSS089 — Sistem açılınca olay biter mi? Hayır. Veri ihlali, oturum/anahtar yenileme, tedarikçi etkisi, yoğun izleme ve bildirim aylar sürebilir.

SSS090 — Olay sonrası toplantıda kim suçlanmalı? Hiç kimse hedef olmamalıdır. Kök neden, tasarım ve süreç başarısızlığı kanıtla incelenip sahipli düzeltmeye dönüştürülür.

J. Fidye, hukuk ve iletişim

SSS091 — Fidye ödemek yasal mı? Ülke, yaptırım ve aktöre göre hukuki risk taşır. Hukuk, kolluk ve yetkili makam değerlendirmesi olmadan karar verilmemelidir.

SSS092 — Ödeme yapılırsa veri silinir mi? Garanti yoktur. Kopya kalabilir, yeniden satılabilir veya başka aktör erişimi kullanabilir.

SSS093 — Ödeme yapılırsa şifre çözücü kesin çalışır mı? Hayır. Araç yavaş, hatalı veya eksik olabilir; sistem bağımlılıklarını ve veri sızıntısını düzeltmez.

SSS094 — Saldırganla çalışan konuşabilir mi? Hayır; tüm temas yetkili, hukuk onaylı tek kanaldan yürütülmelidir. Bireysel temas delil ve yaptırım riskini büyütür.

SSS095 — Kamuya hemen “veri çalınmadı” denebilir mi? Yeterli kanıt olmadan hayır. “Şu anda kanıt yok, inceleme sürüyor” gibi kesinlik dereceli dil kullanılır.

SSS096 — Fail adı açıklanmalı mı? Yalnız resmî atıf ve iletişim/hukuk gerekçesi varsa. Yanlış atıf güveni ve soruşturmayı zedeler.

SSS097 — Müşteri ne zaman bilgilendirilir? Yasal süre, risk ve doğrulanmış kapsam temelinde gecikmeden. İlk bildirim tam ayrıntı içermeyebilir; güncelleme planı verilmelidir.

SSS098 — Çalışanlara ne söylenmeli? Güvenilir iletişim kanalı, yapılacak/yapılmayacak eylem, hangi hizmetin etkili olduğu ve bir sonraki güncelleme zamanı açıkça belirtilmelidir.

SSS099 — Sızıntı sitesini kendimiz kontrol edelim mi? Gereksiz erişim teknik, hukuki ve psikolojik risk taşır. Yetkili uzman/kolluk kanalı ve kanıt prosedürü kullanılmalıdır.

SSS100 — Fidye tutarı toplam zarar mıdır? Hayır. Kesinti, kurtarma, hukuk, bildirim, finansman ve müşteri kaybı çoğu zaman daha büyüktür; Change Healthcare bunun belirgin örneğidir. S49

K. İş sürekliliği ve felaket kurtarma

SSS101 — BCP ile DR aynı mı? Hayır. BCP teknoloji dönmeden hizmeti sürdürür; DR teknoloji ve veriyi güvenli biçimde geri getirir.

SSS102 — RTO ve RPO kim belirler? İş/klinik/operasyon sahibi, BT ve yönetim birlikte belirler. Yalnız teknik ekibin tahmini gerçek hizmet toleransı değildir.

SSS103 — Manuel süreç her zaman güvenli mi? Hayır. Sahtecilik, çift kayıt, gizlilik ve personel kapasitesi riski taşır; numara serisi, çift onay ve mutabakat gerekir.

SSS104 — Tüm sistemler aynı anda geri açılmalı mı? Hayır. Kimlik ve temel servislerden başlayıp kritik uygulamalara kontrollü dalgalarla geçilir.

SSS105 — Clean room nedir? Şüpheli üretimden ayrılmış, güvenilir yönetim ve telemetriyle geri yükleme/inceleme yapılan ortamdır.

SSS106 — Kurtarmada önce hangi sistem gelir? Hizmete göre değişir; çoğunlukla güvenilir kimlik, DNS, zaman, sertifika ve ağ güvenliği uygulamalardan önce gerekir.

SSS107 — Felaket kurtarma testi üretimi bozmaz mı? İyi tasarlanırsa izole ve kontrollü yapılır. Test edilmemiş planın gerçek olayda daha büyük kesinti yaratma riski vardır.

SSS108 — Degrade mod ne kadar sürer? BIA'da belirlenen personel, veri doğruluğu ve güvenlik kapasitesine kadar. “Sonsuza kadar kâğıtla devam” plan değildir.

SSS109 — Tedarikçi yoksa manuel alternatif yeterli mi? Yalnız kapasite, veri, hukuk ve mutabakat test edildiyse. Change/CDK vakaları uzun zincirlerde alternatif zorluğunu gösterir. S48 S52

SSS110 — Kurtarma başarısı nasıl ölçülür? Gerçek RTO/RPO, veri bütünlüğü, güvenlik telemetrisi, iş sahibi kabulü ve yeniden saldırı bulunmamasıyla.

L. Tedarikçi ve sektör soruları

SSS111 — MSP neden ortak hata alanıdır? Bir yönetim erişimi çok sayıda müşteriye uzanabilir. Müşteri izolasyonu, ayrı kimlik ve acil erişim iptali şarttır.

SSS112 — Tedarikçi anketi yeterli mi? Hayır. Sözleşme, erişim teknik kontrolü, log, alt yüklenici, kesinti tatbikatı ve bildirim kanıtı gerekir.

SSS113 — Hastaneler neden daha çok baskı hisseder? Kesinti hasta bakımını etkiler, veri hassastır ve eski/özel cihazlar kurtarmayı zorlaştırır.

SSS114 — Belediyeler neden hedef olur? Geniş kamu hizmeti, eski sistem, sınırlı kaynak ve vatandaş verisi; kesintiye yüksek kamu baskısı yaratır.

SSS115 — Üniversiteler neden risklidir? Açık ağ kültürü, heterojen cihaz, sürekli kullanıcı devri ve değerli araştırma verisi ortak zorluktur.

SSS116 — Bankalar güvenli olduğu hâlde neden hedeflenir? Yüksek değer ve düzenleyici baskı sürer; saldırgan doğrudan banka yerine çağrı merkezi veya tedarikçiyi hedefleyebilir.

SSS117 — Enerji olayında OT etkilenmediyse neden operasyon durur? Faturalama, planlama ve güvenli işletme verisine güven kaybolabilir. Colonial, iş ağı olayının fiziksel hizmet kararını etkilediğini gösterdi. S40

SSS118 — Üretimde yama neden gecikir? Duruş, sertifikasyon ve vendor desteği gerekebilir; bu gecikme telafi edici kontrol ve son tarihli risk kabulüyle yönetilmelidir.

SSS119 — Okullarda en kritik veri nedir? Öğrenci/veli kimlik, sağlık, değerlendirme ve koruma kayıtları; çocuklara yönelik uzun vadeli zarar riski taşır.

SSS120 — Lojistikte en kritik süreklilik konusu nedir? Rota, stok, sevk, gümrük ve müşteri entegrasyonunun manuel asgari kapasiteyle güvenli sürdürülmesi.

M. KOBİ ve ev kullanıcıları

SSS121 — KOBİ'nin ilk üç yatırımı ne olmalı? Kritik hesaplarda phishing-resistant MFA, otomatik/KEV öncelikli güncelleme ve test edilmiş 3-2-1/immutable yedek. Ardından EDR ve olay planı.

SSS122 — Güvenlik bütçesi küçükse SIEM gerekir mi? Tam ölçekli SIEM şart olmayabilir; kimlik, uç nokta ve yedek sağlayıcının merkezî uyarıları, yönetilen SOC/MDR ve temel log saklama kullanılabilir.

SSS123 — Ücretsiz antivirüs yeterli mi? Güncel yerleşik koruma evde iyi tabandır; yedek, MFA, güncelleme ve standart kullanıcı hesabı olmadan yeterli değildir.

SSS124 — Harici disk sürekli bağlı olabilir mi? RaaS/şifreleme riskine karşı hayır; yedek sonrası ayrılmalı veya değiştirilemez koruma kullanılmalıdır.

SSS125 — Evde en önemli hesap hangisidir? Ana e-posta ve parola yöneticisi; diğer hesapların kurtarma anahtarı oldukları için en güçlü MFA ile korunmalıdır.

SSS126 — NAS cihazı güvenli midir? Doğru güncelleme, benzersiz parola, MFA, internete kapalı yönetim, ayrı ağ ve bağımsız yedekle güvenli hâle gelir; tek başına yedek değildir.

SSS127 — Fidye notu gören ev kullanıcısı ne yapmalı? İnterneti ayır, cihazı kullanmayı bırak, başka temiz cihazdan hesapları koru ve güvenilir profesyonel destek al; notla iletişim kurma.

SSS128 — Bulut fotoğrafları yedek sayılır mı? Sürümleme/çöp kutusu varsa bir katmandır; hesap ele geçirme veya senkron silme riskine karşı ayrı kopya gerekir.

SSS129 — Parola yöneticisi tek hata noktası değil mi? Değerli hedeftir ama benzersiz güçlü parolaları mümkün kılar. Güçlü ana parola, phishing-resistant MFA ve kurtarma planıyla risk azaltılır.

SSS130 — Aile güvenlik eğitimi nasıl yapılır? Kısa kurallar: kod paylaşma, beklenmeyen destek talebini bağımsız doğrula, şüpheli olayı utanmadan bildir, kritik hesapta MFA kullan.

N. Ölçüm ve yönetişim

SSS131 — Yönetim kurulu hangi RaaS ölçülerini görmeli? Kritik hizmet RTO/RPO testi, MFA'sız yol, kalıcı admin, KEV yaşı, EDR/log kör noktası, yedek geri yükleme ve açık olay bulgusu.

SSS132 — “MFA kapsamı yüzde 100” yeterli ölçü mü? Hayır. Eski protokol, istisna ve sıfırlama yolu kalabilir; MFA'sız başarılı oturum ve phishing-resistant oranı ölçülmelidir.

SSS133 — Yedek başarı oranı neden yanıltıcıdır? İşin tamamlanması verinin geri açılabildiğini göstermez. Restore testi, bütünlük ve gerçek RTO/RPO gerekir.

SSS134 — Risk kabulü kimde olmalı? Etkilenen iş hizmetinin yetkili yöneticisinde; BT tek başına iş riskini kabul etmemelidir.

SSS135 — Güvenlik olgunluğu nasıl kanıtlanır? Politika varlığıyla değil negatif test, tatbikat, geri yükleme, alarm ve düzeltici faaliyet kapanışıyla.

SSS136 — RaaS riski yıllık denetimle yönetilir mi? Hayır. Dış yüzey, kimlik, grup ve zafiyetler sürekli değişir; periyodik denetim sürekli kontrol sağlığıyla tamamlanır.

SSS137 — En iyi KPI nedir? Tek KPI yoktur. Önleme, tespit, kontrol altına alma, kurtarma ve iş sürekliliği ölçüleri dengeli kullanılmalıdır.

SSS138 — “Hiç olay yaşamadık” iyi performans kanıtı mı? Olay olmayabilir veya görünürlük yetersiz olabilir. Kontrollerin tatbikat ve negatif testte çalışması gerekir.

SSS139 — Tedarikçi riski kime aittir? İş sahibi, satın alma, hukuk ve güvenlik ortak yönetir; “sözleşmede tedarikçiye devrettik” riskin etkisini kaldırmaz.

SSS140 — Kaynak kalitesi nasıl ölçülür? Birincil kayıt, yöntem, tarih, bağımsız doğrulama ve iddiayla doğrudan ilişki aranır; sızıntı sitesi veya tek haber kesin kanıt değildir.

O. Modern tehditler ve gelecek

SSS141 — Yapay zekâ RaaS saldırılarını tamamen otomatikleştirdi mi? Kamu değerlendirmeleri yakın vadede AI'nın mevcut sosyal mühendislik, keşif ve analiz hızını artırdığını; tüm zinciri sihirli biçimde otonomlaştırmadığını belirtir. S23

SSS142 — Deepfake yardım masasını etkiler mi? Ses/görüntü taklidi bilgiye dayalı doğrulamayı zayıflatır. Cihaz bağlı kanıt, geri arama ve çift onay gerekir.

SSS143 — Bulut ransomware neden artıyor? Kimlik ve kontrol düzlemi çok sayıda veri/iş yüküne ulaşır; saldırgan yedek ve politika üzerinde yüksek etki kurabilir. S14

SSS144 — Sanallaştırma hedeflemesi neden modern trend? Bir hipervizör veya yönetim sunucusu çok sayıda sistemi aynı anda etkiler ve EDR kapsamı daha sınırlı olabilir. S13

SSS145 — Şifreleme önemini kaybediyor mu? Hayır; fakat veri hırsızlığı ve yalnız gasp daha görünür. Savunma hem erişilebilirlik hem gizlilik senaryosunu kapsamalıdır.

SSS146 — Kolluk operasyonları işe yarıyor mu? Evet; altyapı, gelir ve güveni bozar, anahtar sağlayabilir ve riski yükseltir. Ancak affiliate göçü nedeniyle kalıcı savunma yine gerekir.

SSS147 — RaaS grupları birleşiyor mu? Bazıları ortak marka/kartel ilan eder; bunlar pazarlama olabilir. Altyapı, personel ve gelir kanıtı olmadan kalıcı birleşme varsayılmaz.

SSS148 — 2026'da en tehlikeli grup hangisi? Tek isim vermek yanıltıcıdır. FBI 2025 verisi çok sayıda varyantı, CCB 2026 DragonForce büyümesini gösterir; kurum için en tehlikeli olan kendi açık kimlik ve hizmet yoludur. S10 S36

SSS149 — RaaS tamamen yok edilebilir mi? Suç ekonomisi bütünüyle kısa sürede yok olmayabilir; fakat erişim maliyeti artırılıp ödeme baskısı azaltılarak olay sıklığı ve etkisi düşürülebilir.

SSS150 — Geleceğe en dayanıklı yatırım nedir? Marka IOC'si değil; güçlü kimlik, ayrıcalık ayrımı, görünürlük, değiştirilemez yedek, temiz kurtarma ve iş sürekliliğini birlikte geliştiren mimari.

RaaS açısından neden önemli?

Bu 150 soru, RaaS hakkında karar anında en çok karıştırılan kavramları kısa ve kanıt temelli yanıtlarla netleştirir. Soru seti; marka merakından çok erişim, tespit, veri, yedek, hukuk ve iş sürekliliğine odaklanarak rehberin savunma amacını korur.

RaaS Hakkında Yanlış Bilinenler

Aşağıdaki 100 yanlış inanış, teknik ekip kadar yönetim, hukuk, iletişim ve ev kullanıcılarının kararlarını da etkiler. Her düzeltme, RaaS'ın gerçek ekonomik ve operasyonel yapısına bağlanmıştır.

A. Tanım ve ekosistem yanlışları

Y001 — Yanlış inanış: RaaS yalnız başka bir ransomware türüdür. Gerçek: RaaS, yazılımın yanında operatör, affiliate, erişim ve gasp altyapısını içeren hizmet/gelir modelidir.

Y002 — Yanlış inanış: Her ransomware olayı RaaS'tır. Gerçek: Tekil aktör veya kapalı ekip de ransomware kullanabilir; hizmet ilişkisi kanıtlanmalıdır.

Y003 — Yanlış inanış: RaaS operatörü her saldırıyı kendisi yapar. Gerçek: Hedefe erişim ve saha operasyonu çoğu zaman bağımsız affiliate veya IAB üzerinden yürür.

Y004 — Yanlış inanış: Ransomware'ın amacı sadece dosya şifrelemektir. Gerçek: Veri hırsızlığı, yayın tehdidi ve iş kesintisi modern gaspın eşit derecede önemli parçalarıdır.

Y005 — Yanlış inanış: Şifreleme yoksa ransomware/RaaS olayı yoktur. Gerçek: Cl0p gibi kampanyalar veri hırsızlığı odaklı gaspın şifrelemesiz gerçekleşebildiğini gösterdi. S31

Y006 — Yanlış inanış: RaaS, SaaS kadar düzenli ve güvenilir bir işletmedir. Gerçek: Suç ekosistemi çıkış dolandırıcılığı, anlaşmazlık ve kolluk sızıntısıyla kırılgandır; benzetme yalnız hizmet mantığı içindir.

Y007 — Yanlış inanış: Affiliate teknik açıdan acemidir. Gerçek: Bazı affiliate'ler yüksek beceri ve kurumsal ağ deneyimine sahiptir; hizmet modeli yalnız giriş engelini düşürür.

Y008 — Yanlış inanış: İlk erişim ile şifreleme aynı aktörün işidir. Gerçek: Erişim IAB'den satın alınabilir ve günler sonra başka affiliate tarafından kullanılabilir.

Y009 — Yanlış inanış: Kripto para ödemeyi tamamen izlenemez yapar. Gerçek: Kamu zincirleri kalıcı işlem izi bırakır; kimlik için ek adli ve borsa kanıtı gerekir.

Y010 — Yanlış inanış: RaaS yalnız karanlık web sitesi demektir. Gerçek: Site yalnız görünür baskı yüzüdür; kimlik, erişim, barındırma, veri ve para aktörleri daha geniş ekosistemi oluşturur.

B. Grup ve atıf yanlışları

Y011 — Yanlış inanış: Sızıntı sitesinde adı geçen her kurum kesin mağdurdur. Gerçek: Kayıt yanlış, tekrar, tarih dışı veya yalnız iddia olabilir; birincil doğrulama gerekir.

Y012 — Yanlış inanış: Fidye notundaki ad saldırgan kimliğini kanıtlar. Gerçek: Not kopyalanabilir, sahte olabilir veya affiliate yalnız markayı kullanır.

Y013 — Yanlış inanış: Bir grup kapatıldıysa tüm üyeleri yakalanmıştır. Gerçek: Altyapı bozma kapasiteyi düşürür; aktör ve affiliate'ler başka markalara geçebilir.

Y014 — Yanlış inanış: LockBit 2024'te tamamen yok oldu. Gerçek: Operasyon ciddi darbe aldı fakat sonraki faaliyet ve marka dönüşleri ekosistem sürekliliğini gösterdi. S11

Y015 — Yanlış inanış: Conti adı artık görünmüyorsa risk yoktur. Gerçek: Marka kapandı; insan, erişim ve yöntem mirası başka yapılara dağıldı.

Y016 — Yanlış inanış: ALPHV 2025'teki yargı haberinde geçtiğine göre o tarihte aktifti. Gerçek: Haber 2023 eylemleri hakkındaki suç kabulünü anlatır; marka 2024'te çöktü. S60

Y017 — Yanlış inanış: Aynı kod iki olayın aynı kişilerce yapıldığını kanıtlar. Gerçek: Kod satılabilir, sızabilir veya affiliate'lerce paylaşılabilir; altyapı ve davranış kanıtı gerekir.

Y018 — Yanlış inanış: “Kartel” ilanı bütün grupların tek komuta altında olduğunu gösterir. Gerçek: Suç pazarlaması olabilir; gelir, altyapı ve personel ilişkisi bağımsız doğrulanmalıdır.

Y019 — Yanlış inanış: En çok DLS kaydı olan grup kesin en başarılıdır. Gerçek: Yayın ve doğrulama politikaları değişir; ödeme yapanlar listelenmeyebilir ve tekrarlar olabilir.

Y020 — Yanlış inanış: Fail atfı olay müdahalesinin ilk hedefidir. Gerçek: İlk hedef insan güvenliği, yayılmayı durdurma, veri/hizmet kapsamı ve temiz kurtarmadır; atıf daha sonra destekleyebilir.

C. İlk erişim ve kimlik yanlışları

Y021 — Yanlış inanış: Güçlü parola varsa MFA gereksizdir. Gerçek: Parola sızıntı, bilgi hırsızı ve sosyal mühendislikle ele geçirilebilir; phishing-resistant MFA ikinci bağımsız bariyerdir.

Y022 — Yanlış inanış: MFA tüm hesap ele geçirmelerini önler. Gerçek: Token hırsızlığı, yardım masası sıfırlama, eski protokol ve kötü cihaz MFA'yı çevreleyebilir.

Y023 — Yanlış inanış: SMS MFA kusursuzdur. Gerçek: SIM ve phishing riskleri vardır; FIDO/passkey daha güçlüdür.

Y024 — Yanlış inanış: Parola değişince saldırgan otomatik çıkar. Gerçek: Aktif oturum, refresh token, cihaz kaydı ve OAuth izni ayrıca iptal edilmelidir.

Y025 — Yanlış inanış: VPN içindeki her kullanıcı güvenilirdir. Gerçek: VPN yalnız tüneldir; çalınmış hesap ve güvensiz cihazı güvenilir yapmaz.

Y026 — Yanlış inanış: Servis hesabı insan olmadığı için ele geçirilemez. Gerçek: Uzun ömürlü sır ve geniş yetki, servis hesaplarını çekici hedef yapar.

Y027 — Yanlış inanış: Eski hesap kullanılmıyorsa zararsızdır. Gerçek: Aktif ve izlenmeyen hesap düşük görünürlüklü giriş yolu olabilir.

Y028 — Yanlış inanış: Yardım masası yalnız müşteri hizmetidir. Gerçek: Parola ve MFA sıfırladığı için kimlik güven zincirinin kritik kontrolüdür.

Y029 — Yanlış inanış: Domain admin hesabını günlük kullanmak işleri hızlandırır ve sorun olmaz. Gerçek: Günlük web/e-posta riskini Tier-0 yetkisine taşır; ayrı yönetim hesabı/cihazı gerekir.

Y030 — Yanlış inanış: Passkey varsa yama ve EDR gereksizdir. Gerçek: Passkey kimlik avına direnç sağlar; yazılım zafiyeti, kötü cihaz ve veri çıkışını çözmez.

D. Tespit ve güvenlik ürünü yanlışları

Y031 — Yanlış inanış: Antivirüs varsa ransomware olamaz. Gerçek: Meşru araç, yeni örnek ve kimlik tabanlı davranış imza savunmasını aşabilir.

Y032 — Yanlış inanış: EDR alarm vermediyse sistem temizdir. Gerçek: Ajan kör noktası veya kimlik/bulut katmanı olayı olabilir; telemetri eksikliği belirsizliktir.

Y033 — Yanlış inanış: SIEM'e tüm logları atmak görünürlük sağlar. Gerçek: Alan kalitesi, zaman, sahipli kural ve yeterli saklama olmadan yalnız maliyet/gürültü artar.

Y034 — Yanlış inanış: XDR insan analisti gereksiz kılar. Gerçek: Korelasyon bağlam ve yanlış pozitif değerlendirmesi için insan/süreç gerektirir.

Y035 — Yanlış inanış: SOAR tüm kritik alarmlarda ağı otomatik kapatmalıdır. Gerçek: Kontrolsüz otomasyon klinik/üretim zararına yol açabilir; etki sınırı ve insan onayı gerekir.

Y036 — Yanlış inanış: IOC listesi güncelse korunuruz. Gerçek: Göstergeler hızla değişir; davranış, kimlik ve yönetim düzlemi tespitleri gerekir.

Y037 — Yanlış inanış: Çok alarm daha iyi SOC demektir. Gerçek: Değer, karar verilebilir ve sahipli alarmda; yüksek sayı yorgunluk yaratabilir.

Y038 — Yanlış inanış: Tehdit avcılığı rastgele geniş aramadır. Gerçek: Test edilebilir hipotez, gerekli veri ve sonuçtan kalıcı tespit üretimi gerekir.

Y039 — Yanlış inanış: Günlükleri 7 gün tutmak her olaya yeter. Gerçek: IAB erişimi ile etki arasında haftalar/aylar olabilir; risk bazlı daha uzun arşiv gerekir.

Y040 — Yanlış inanış: Ülke/IP engelleme RaaS'ı çözer. Gerçek: Meşru bulut, VPN ve ele geçirilmiş altyapı kullanılabilir; kimlik ve davranış bağlamı gerekir.

E. Yedek ve kurtarma yanlışları

Y041 — Yanlış inanış: Yedeğimiz var, fidye sorunumuz yok. Gerçek: Yedek silinebilir, bozuk olabilir ve veri sızıntısını geri alamaz; test ve iş sürekliliği gerekir.

Y042 — Yanlış inanış: Bulut senkronizasyonu tam yedektir. Gerçek: Silme/şifreleme de eşitlenebilir; sürümleme ve bağımsız kopya gerekir.

Y043 — Yanlış inanış: Snapshot her zaman bağımsız yedektir. Gerçek: Aynı depolama ve yönetim alanındaysa saldırgan tarafından aynı anda kaybedilebilir.

Y044 — Yanlış inanış: Immutable etiketi yedeği otomatik güvenli yapar. Gerçek: Ayrı kimlik, doğru kilit, anahtar, katalog ve restore testi olmadan etiket yeterli değildir.

Y045 — Yanlış inanış: Yedek işi “başarılı”ysa geri dönüş garanti. Gerçek: Veri tutarlılığı ve uygulama bağımlılığı ancak restore testinde anlaşılır.

Y046 — Yanlış inanış: En yeni yedek daima en temizdir. Gerçek: Uzun kalıcılık varsa yeni kopya kötü yapı veya bozuk veri içerebilir; geçmiş noktalar korunur.

Y047 — Yanlış inanış: Tüm sistemi eski imaja dönmek en hızlı yoldur. Gerçek: Eski zafiyet ve kalıcılık geri gelebilir; temiz oda ve güvenilir imaj gerekir.

Y048 — Yanlış inanış: DR planı veri sızıntısını çözer. Gerçek: DR erişilebilirliği geri getirir; gizlilik kaybı, bildirim ve mağdur desteği ayrı süreçtir.

Y049 — Yanlış inanış: Air gap yalnız kasada duran banttır. Gerçek: Güçlü mantıksal ve kimlik ayrımı da olabilir; sürekli ortak yönetim gerçek ayrımı zayıflatır.

Y050 — Yanlış inanış: RPO/RTO'yu BT tek başına belirler. Gerçek: İş sahibi etki ve toleransı belirler; BT kapasite ve maliyeti doğrular.

F. Fidye, hukuk ve ekonomi yanlışları

Y051 — Yanlış inanış: Fidye ödenirse olay en ucuz şekilde biter. Gerçek: Ödeme yanında kesinti, kurtarma, hukuk, bildirim ve tekrar riskleri sürer; toplam maliyet çoğu kez daha büyüktür.

Y052 — Yanlış inanış: Suçlu ödeme sonrası veriyi mutlaka siler. Gerçek: Silme beyanı bağımsız doğrulanamaz; kopya ve yeniden satış riski kalır.

Y053 — Yanlış inanış: Decryptor almak tüm sistemleri anında açar. Gerçek: Araç yavaş/bozuk olabilir; büyük ortamda haftalar sürebilir ve bütünlük doğrulaması gerekir.

Y054 — Yanlış inanış: Fidye ödemek her yerde kesin yasaldır. Gerçek: Yaptırım, aktör ve ülke kuralları değişir; hukuk ve yetkili makam değerlendirmesi gerekir.

Y055 — Yanlış inanış: Sigorta varsa ödeme ve olay yönetimi otomatik çözülür. Gerçek: Poliçe limit/şart taşır ve temel kontrolleri, karar yetkisini veya itibarı devralmaz.

Y056 — Yanlış inanış: Kripto cüzdan adresi saldırganın gerçek adıdır. Gerçek: Adres takma kimliktir; kişi atfı için borsa, cihaz, altyapı ve yargı kanıtı gerekir.

Y057 — Yanlış inanış: DLS'deki fidye talebi grubun kazancıdır. Gerçek: Talep ödeme değildir; indirim, hiç ödeme yapılmaması ve gelir paylaşımı bilinmeyebilir.

Y058 — Yanlış inanış: FBI/IC3 kayıpları toplam küresel ransomware maliyetidir. Gerçek: Şikâyet ve raporlama sınırlıdır; dolaylı kesinti ve bildirilmeyen olaylar rakamı eksik bırakır. S10

Y059 — Yanlış inanış: Ödeme yapmak veri ihlali bildirimini kaldırır. Gerçek: Veri erişimi/sızıntısı gerçekleştiyse hukuki risk ve bildirim devam eder.

Y060 — Yanlış inanış: Ödememe kararı teknik ekibin sorumluluğudur. Gerçek: Hukuk, yaptırım, insan güvenliği, operasyon, yönetim ve kolluk birlikte yönetişim kararı verir.

G. Olay müdahalesi ve iletişim yanlışları

Y061 — Yanlış inanış: Fidye notunu silmek sistemi temizler. Gerçek: Not delildir; saldırgan erişimi ve şifrelenmiş/veri kapsamını değiştirmez.

Y062 — Yanlış inanış: İlk iş tüm cihazları kapatmaktır. Gerçek: Kör kapatma kritik hizmet ve uçucu delili bozabilir; kontrollü izolasyon/karar gerekir.

Y063 — Yanlış inanış: Olayı gizlemek kurum itibarını korur. Gerçek: Gecikmiş veya yanıltıcı iletişim hukuki ve güven zararını büyütebilir.

Y064 — Yanlış inanış: İlk saatte fail adı açıklanmalıdır. Gerçek: Atıf zaman alır; doğrulanan etki ve kullanıcı eylemi önce gelir.

Y065 — Yanlış inanış: Yedekten dönünce adli inceleme gereksizdir. Gerçek: İlk erişim, veri sızıntısı ve kalıcılık bilinmeden tekrar saldırı ve yanlış bildirim riski sürer.

Y066 — Yanlış inanış: Olay sırasında normal kurumsal e-posta güvenlidir. Gerçek: Kimlik/e-posta etkilenmiş olabilir; bağımsız temiz iletişim kanalı gerekir.

Y067 — Yanlış inanış: Hukuk ekibi yalnız bildirim için çağrılır. Gerçek: Delil, ayrıcalık, sözleşme, yaptırım ve iletişim kararında ilk saatlerden itibaren rol alır.

Y068 — Yanlış inanış: Olay sonrası bir çalışanı işten çıkarmak kök nedeni çözer. Gerçek: Tasarım, yetki, yardım masası ve tespit zinciri düzeltilmezse aynı yol sürer.

Y069 — Yanlış inanış: Tüm parolaları aynı anda sıfırlamak her zaman doğrudur. Gerçek: Temiz yönetim ve sıralama yoksa hizmet kilitlenir, saldırgan uyarılır ve servis hesapları bozulur.

Y070 — Yanlış inanış: Kamu açıklaması teknik rapor kadar ayrıntılı olmalı. Gerçek: Kullanıcıya doğrulanan etki, yapılacak eylem ve güncelleme zamanı sade dille verilmelidir; operasyonel sır paylaşılmaz.

H. Sektör ve tedarikçi yanlışları

Y071 — Yanlış inanış: Yalnız büyük şirketler RaaS hedefidir. Gerçek: Küçük kurumlar zayıf erişim ve kritik yerel hizmet nedeniyle fırsatçı hedef olabilir.

Y072 — Yanlış inanış: Hastaneler etik nedenlerle hedef alınmaz. Gerçek: Finansal aktörler sağlık hizmetini hedeflemeye devam eder; resmî uyarılar bunu belgeler. S30 S35

Y073 — Yanlış inanış: Belediyenin verisi değerli değildir. Gerçek: Vatandaş, vergi, ruhsat ve sosyal hizmet verisiyle kamu kesintisi güçlü gasp baskısı yaratır.

Y074 — Yanlış inanış: Üniversite ağı açık olmalı, segmentasyon yapılamaz. Gerçek: Akademik açıklık ile yönetim, finans ve araştırma güven alanı ayrılabilir.

Y075 — Yanlış inanış: OT internete bağlı değilse ransomware etkilenmez. Gerçek: BT bağımlılığı, vendor erişimi ve mühendislik cihazı köprü olabilir; Colonial'da iş ağı etkisi operasyon kararını durdurdu. S40

Y076 — Yanlış inanış: Güvenliği tedarikçiye devretmek riski devreder. Gerçek: Hizmet ve müşteri etkisi kurumda kalır; denetim, sözleşme ve alternatif plan gerekir.

Y077 — Yanlış inanış: Kaseya olayı tek bir şirketin iç olayıydı. Gerçek: MSP/alt müşteri zinciri nedeniyle yönetim yazılımı ortak hata alanına dönüştü. S44

Y078 — Yanlış inanış: Change Healthcare yalnız kendi müşterilerini etkiledi. Gerçek: ABD sağlık ödeme ve talep ekosisteminde geniş sağlayıcı/nakit akışı etkisi yarattı. S49 S50

Y079 — Yanlış inanış: CDK olayı yalnız web sitesini kapattı. Gerçek: Bayilerin satış, servis, CRM, stok ve muhasebe çekirdek işlevleri aksadı. S52

Y080 — Yanlış inanış: Synnovis olayı yalnız laboratuvarın BT sorunudur. Gerçek: 11.000'den fazla randevu/işlem gecikti ve Parlamento kaydı bir hasta ölümüne katkı bildirdi. S55

I. Yönetişim ve ölçüm yanlışları

Y081 — Yanlış inanış: RaaS riski CISO'nun tek başına sorunudur. Gerçek: Kritik hizmet, hukuk, tedarikçi, iletişim ve kaynak kararları yönetim kurulu/iş sahipliği gerektirir.

Y082 — Yanlış inanış: Politika yayımlandıysa kontrol uygulanmıştır. Gerçek: Negatif test, log, tatbikat ve gerçek restore kanıtı gerekir.

Y083 — Yanlış inanış: Yüzde 100 yama uyumu her riski kapatır. Gerçek: Envanter eksik, yanlış yapılandırma veya sıfır gün kalabilir; KEV ve dış yüzey ayrı ölçülür.

Y084 — Yanlış inanış: MFA kullanıcı sayısı en iyi kimlik KPI'ıdır. Gerçek: MFA'sız başarılı yol, phishing-resistant oran, istisna ve sıfırlama güvenliği daha anlamlıdır.

Y085 — Yanlış inanış: Yedeklenen TB miktarı dayanıklılığı gösterir. Gerçek: Geri yükleme başarısı, veri bütünlüğü ve iş hizmeti RTO/RPO'su önemlidir.

Y086 — Yanlış inanış: Hiç ransomware yaşamadık, kontrollerimiz güçlü. Gerçek: Şans veya görünürlük eksikliği olabilir; tatbikat ve test gerekir.

Y087 — Yanlış inanış: Risk kabulü süresiz olabilir. Gerçek: Sahip, gerekçe, telafi edici kontrol, bitiş tarihi ve yeniden değerlendirme gerekir.

Y088 — Yanlış inanış: Yıllık farkındalık videosu insan riskini çözer. Gerçek: Rol bazlı pratik, kolay bildirim ve güvenli sistem tasarımı gerekir.

Y089 — Yanlış inanış: En pahalı güvenlik ürünü en iyi savunmadır. Gerçek: Envanter, kimlik, yedek ve süreç boşluğu varsa ürün değeri düşer; risk yoluna göre yatırım yapılır.

Y090 — Yanlış inanış: Yönetim kuruluna grup isimleri sunmak yeterlidir. Gerçek: Kritik hizmet, kontrol boşluğu, gerçek kurtarma süresi ve kalan risk karar için daha değerlidir.

J. Modern tehdit ve gelecek yanlışları

Y091 — Yanlış inanış: Yapay zekâ tamamen otonom RaaS çeteleri yarattı. Gerçek: Güncel kamu değerlendirmeleri AI'nın mevcut sosyal mühendislik ve analiz faaliyetlerini hızlandırdığını, sihirli uçtan uca otonomi olmadığını belirtir. S23

Y092 — Yanlış inanış: Deepfake'e karşı çalışan sesi tanırsa yeter. Gerçek: Ses/görüntü taklit edilebilir; cihaz bağlı doğrulama, geri arama ve çift onay gerekir.

Y093 — Yanlış inanış: Bulut sağlayıcı ransomware'ı otomatik önler. Gerçek: Çalınmış müşteri kimliğiyle kontrol düzlemi ve yedekler kötüye kullanılabilir; paylaşılan sorumluluk sürer. S14

Y094 — Yanlış inanış: Sanal makineler fiziksel sunucudan otomatik daha güvenlidir. Gerçek: Hipervizör ele geçirilirse çok sayıda VM aynı anda etkilenebilir.

Y095 — Yanlış inanış: Veri hırsızlığı arttığı için yedek artık gereksiz. Gerçek: Şifreleme ve hizmet bozma sürer; gizlilik ve erişilebilirlik kontrolleri birlikte gerekir.

Y096 — Yanlış inanış: Kolluk operasyonları anlamsızdır çünkü gruplar geri döner. Gerçek: Altyapı, gelir, güven ve anahtar kapasitesini bozar; ancak kurumsal savunma yine devam etmelidir.

Y097 — Yanlış inanış: Geleceğin savunması yalnız daha çok AI ürünüdür. Gerçek: Güçlü kimlik, en az yetki, görünürlük, yedek ve süreklilik temel kalır; AI bunları destekleyebilir.

Y098 — Yanlış inanış: Ev kullanıcısının verisi suçlular için değersizdir. Gerçek: Hesap kurtarma, kimlik, fotoğraf ve finans verisi dolandırıcılık/gasp için değer taşır.

Y099 — Yanlış inanış: Bir kez fidye ödeyen kurum artık hedef olmaz. Gerçek: Ödeme istekliliği veya kalan erişim yeniden saldırı ve erişim satışı riskini artırabilir.

Y100 — Yanlış inanış: RaaS'a karşı yüzde 100 güvenlik mümkündür. Gerçek: Amaç sıfır risk vaadi değil; olasılığı düşürmek, erken tespit, etkiyi sınırlamak ve güvenli kurtarmaktır.

RaaS açısından neden önemli?

RaaS olaylarında yanlış varsayım, yanlış teknik kontrolden daha hızlı kriz büyütebilir. Bu 100 düzeltme; marka, MFA, güvenlik ürünü, yedek, ödeme ve iletişim hakkındaki aşırı güveni azaltarak kararları kanıt, katmanlı savunma ve hizmet dayanıklılığına yöneltir.

Güncelleme ve düzeltme politikası

RaaS markaları, bağlı kuruluş ilişkileri, kolluk operasyonları, düzenleyici bildirimler ve ekonomik etkiler zaman içinde değişebilir. Bu nedenle sayfadaki güncel durum ifadeleri araştırma kesim tarihiyle birlikte değerlendirilir. Anlamlı bir olgu değiştiğinde dateModified, sürüm kaydı ve etkilenen bölüm birlikte güncellenmelidir; yalnızca tarihi yenilemek içerik güncellemesi sayılmaz.

Hata veya eksik kaynak bildirimi alındığında önce birincil açıklama, yargı kaydı, düzenleyici bildirim ya da resmî teknik danışma belgesi aranır. Düzeltme, önceki ifadenin neden değiştiğini görünür kılacak biçimde sürüm geçmişine eklenir. Sızıntı sitesi beyanı veya tekil aktör iddiası bağımsız doğrulama olmadan kesin olguya dönüştürülmez.

Sürüm geçmişi

• 1.0 — 22 Temmuz 2026: Kaynak çalışmanın 13 bölümü; 300 terim, 150 sık sorulan soru, 100 yanlış inanış ve 63 kaynak korunarak tek sayfalık web makalesi biçimine dönüştürüldü.

Kaynakça ve kanıt kayıtları

Aşağıdaki kayıtlar metindeki S01–S63 bağlantılarının tam künyelerini gösterir. A düzeyi kaynaklar resmî kurum, yargı/düzenleyici kayıt, mağdur kurum açıklaması veya nihai standarttır. B düzeyi kaynaklar yöntemini açıklayan akademik ya da çok taraflı çalışmalardır. C düzeyi kaynaklar güncel saha gözlemi sunan sektör araştırmalarıdır ve tek başına kesin atıf için kullanılmaz.

S01 — UK National Cyber Security Centre (NCSC): Ransomware, extortion and the cyber crime ecosystem

Ransomware, extortion and the cyber crime ecosystem

• Tarih: 2023
• Kanıt düzeyi: A
• Kaynak türü: Ulusal siber güvenlik kurumu analizi
• Bu rehberde kullanım alanı: RaaS rolleri, bağlı kuruluş modeli, erişim aracıları ve ekosistem ayrımı

S02 — Cybersecurity and Infrastructure Security Agency (CISA): #StopRansomware Guide

#StopRansomware Guide

• Tarih: 19 Ekim 2023 revizyonu
• Kanıt düzeyi: A
• Kaynak türü: Resmî savunma ve müdahale rehberi
• Bu rehberde kullanım alanı: Önleme, tespit, izolasyon, yedekleme ve olay müdahalesi temel önerileri

S03 — National Institute of Standards and Technology (NIST): NIST IR 8374 Rev. 1 — Ransomware Risk Management: A Cybersecurity Framework 2.0 Community Profile

NIST IR 8374 Rev. 1 — Ransomware Risk Management: A Cybersecurity Framework 2.0 Community Profile

• Tarih: Haziran 2026
• Kanıt düzeyi: A
• Kaynak türü: Nihai standart profili
• Bu rehberde kullanım alanı: Ransomware risk yönetimini Govern–Identify–Protect–Detect–Respond–Recover işlevlerine bağlama

S04 — National Institute of Standards and Technology (NIST): Cybersecurity Framework 2.0

Cybersecurity Framework 2.0

• Tarih: 26 Şubat 2024
• Kanıt düzeyi: A
• Kaynak türü: Uluslararası kullanılan çerçeve
• Bu rehberde kullanım alanı: Yönetişim, tedarik zinciri ve kurumsal risk bağlamı

S05 — National Institute of Standards and Technology (NIST): SP 800-61 Rev. 3 — Incident Response Recommendations and Considerations for Cybersecurity Risk Management

SP 800-61 Rev. 3 — Incident Response Recommendations and Considerations for Cybersecurity Risk Management

• Tarih: 3 Nisan 2025
• Kanıt düzeyi: A
• Kaynak türü: Nihai olay müdahalesi standardı
• Bu rehberde kullanım alanı: Olay öncesi hazırlık, müdahale, kurtarma ve öğrenme döngüsü

S06 — National Institute of Standards and Technology (NIST): SP 800-207 — Zero Trust Architecture

SP 800-207 — Zero Trust Architecture

• Tarih: Ağustos 2020
• Kanıt düzeyi: A
• Kaynak türü: Nihai mimari standardı
• Bu rehberde kullanım alanı: Sıfır güven ilkeleri, kaynak odaklı karar ve sürekli doğrulama

S07 — National Institute of Standards and Technology (NIST): SP 1800-35 — Implementing a Zero Trust Architecture

SP 1800-35 — Implementing a Zero Trust Architecture

• Tarih: Haziran 2025
• Kanıt düzeyi: A
• Kaynak türü: Uygulama rehberi
• Bu rehberde kullanım alanı: Zero Trust uygulama desenleri ve birlikte çalışabilir savunma bileşenleri

S08 — UK National Cyber Security Centre (NCSC): Principles for ransomware-resistant cloud backups

Principles for ransomware-resistant cloud backups

• Tarih: 2024
• Kanıt düzeyi: A
• Kaynak türü: Ulusal teknik rehber
• Bu rehberde kullanım alanı: Yedeklerin silme/değiştirme saldırılarına dayanıklılığı ve geri yükleme güveni

S09 — European Union Agency for Cybersecurity (ENISA): ENISA Threat Landscape 2025

ENISA Threat Landscape 2025

• Tarih: 2025
• Kanıt düzeyi: A
• Kaynak türü: AB tehdit görünümü
• Bu rehberde kullanım alanı: Temmuz 2024–Haziran 2025 dönemindeki olay ve tehdit eğilimleri

S10 — Federal Bureau of Investigation (FBI): 2025 Internet Crime Report

2025 Internet Crime Report

• Tarih: 2026
• Kanıt düzeyi: A
• Kaynak türü: Resmî şikâyet ve kayıp istatistikleri
• Bu rehberde kullanım alanı: 2025 varyant sıralaması, kritik sektör şikâyetleri ve raporlama sınırlılıkları

S11 — UK National Cyber Security Centre (NCSC): Annual Review 2025 — Countering the cyber threat

Annual Review 2025 — Countering the cyber threat

• Tarih: 2025
• Kanıt düzeyi: A
• Kaynak türü: Ulusal yıllık tehdit değerlendirmesi
• Bu rehberde kullanım alanı: LockBit sonrasındaki çeşitlenme, hedef seçimi ve yapay zekânın destekleyici rolü

S12 — INTERPOL: New INTERPOL report highlights escalating cyber threats across Asia and South Pacific

New INTERPOL report highlights escalating cyber threats across Asia and South Pacific

• Tarih: 17 Haziran 2026
• Kanıt düzeyi: A
• Kaynak türü: Uluslararası kolluk değerlendirmesi
• Bu rehberde kullanım alanı: 2025–2026 bölgesel suç ekosistemi ve sınır aşan tehdit eğilimleri

S13 — Google Threat Intelligence Group / Mandiant: Ransomware TTPs: Shifting Approaches in a Changing Threat Landscape

Ransomware TTPs: Shifting Approaches in a Changing Threat Landscape

• Tarih: 2026
• Kanıt düzeyi: C
• Kaynak türü: Olay müdahalesi saha araştırması
• Bu rehberde kullanım alanı: 2025 veri hırsızlığı, sanallaştırma hedefleri ve veri sızıntı sitesi ölçüm sınırlılıkları

S14 — Microsoft Threat Intelligence: Storm-0501's evolving techniques lead to cloud-based ransomware

Storm-0501's evolving techniques lead to cloud-based ransomware

• Tarih: 27 Ağustos 2025
• Kanıt düzeyi: C
• Kaynak türü: Üretici tehdit araştırması
• Bu rehberde kullanım alanı: Bulut kimlikleri, yedekler ve bulut içi şifreleme riskleri

S15 — Google Threat Intelligence Group: Defending vSphere from UNC3944: From Help Desk to Hypervisor

Defending vSphere from UNC3944: From Help Desk to Hypervisor

• Tarih: 2025
• Kanıt düzeyi: C
• Kaynak türü: Olay müdahalesi saha araştırması
• Bu rehberde kullanım alanı: Yardım masası sosyal mühendisliği ve sanallaştırma yönetim düzlemi riski

S16 — Check Point Research: The State of Ransomware — Q1 2026

The State of Ransomware — Q1 2026

• Tarih: 2026
• Kanıt düzeyi: C
• Kaynak türü: Sektör tehdit araştırması
• Bu rehberde kullanım alanı: 2026 başı marka/bağlı kuruluş hareketliliği; sızıntı sitesi verisi sınırlılığıyla

S17 — Cybersecurity and Infrastructure Security Agency (CISA): More than a Password

More than a Password

• Tarih: güncel kaynak
• Kanıt düzeyi: A
• Kaynak türü: Resmî kimlik güvenliği rehberi
• Bu rehberde kullanım alanı: Kimlik avına dayanıklı MFA ve FIDO/WebAuthn önceliği

S18 — Cybersecurity and Infrastructure Security Agency (CISA): Guidance for SIEM and SOAR Implementation

Guidance for SIEM and SOAR Implementation

• Tarih: 27 Mayıs 2025
• Kanıt düzeyi: A
• Kaynak türü: Resmî operasyonel rehber
• Bu rehberde kullanım alanı: Merkezî günlükleme, korelasyon, otomasyon ve güvenli SOAR uygulaması

S19 — Cybersecurity and Infrastructure Security Agency (CISA): Zero Trust Microsegmentation Guidance — Part One

Zero Trust Microsegmentation Guidance — Part One

• Tarih: 29 Temmuz 2025
• Kanıt düzeyi: A
• Kaynak türü: Resmî mimari rehber
• Bu rehberde kullanım alanı: Mikrosegmentasyon, yayılma alanını daraltma ve aşamalı uygulama

S20 — NSA ve CISA: Top Ten Cybersecurity Misconfigurations

Top Ten Cybersecurity Misconfigurations

• Tarih: 5 Ekim 2023
• Kanıt düzeyi: A
• Kaynak türü: Ortak siber güvenlik danışma belgesi
• Bu rehberde kullanım alanı: Varsayılan yapılandırmalar, yetersiz segmentasyon, ayrıcalık ve izleme sorunları

S21 — Cybersecurity and Infrastructure Security Agency (CISA): Known Exploited Vulnerabilities Catalog

Known Exploited Vulnerabilities Catalog

• Tarih: sürekli güncellenen katalog
• Kanıt düzeyi: A
• Kaynak türü: Resmî aktif istismar kataloğu
• Bu rehberde kullanım alanı: Risk temelli yama önceliklendirmesi

S22 — MITRE: ATT&CK Enterprise Knowledge Base

ATT&CK Enterprise Knowledge Base

• Tarih: sürekli güncellenen bilgi tabanı
• Kanıt düzeyi: A
• Kaynak türü: Davranış ve teknik bilgi tabanı
• Bu rehberde kullanım alanı: Tespit hipotezleri ve savunma haritalaması; operasyonel saldırı tarifi olmadan

S23 — UK National Cyber Security Centre (NCSC): The near-term impact of AI on the cyber threat

The near-term impact of AI on the cyber threat

• Tarih: 2024
• Kanıt düzeyi: A
• Kaynak türü: Ulusal stratejik değerlendirme
• Bu rehberde kullanım alanı: Yapay zekânın mevcut taktiklerin hacim ve hızını artırması; otonom saldırı abartısının sınırı

S24 — U.S. Department of Justice: U.S. Leads Multi-National Action Against Gameover Zeus Botnet and Cryptolocker Ransomware

U.S. Leads Multi-National Action Against Gameover Zeus Botnet and Cryptolocker Ransomware

• Tarih: 2 Haziran 2014
• Kanıt düzeyi: A
• Kaynak türü: Yargı ve kolluk kaydı
• Bu rehberde kullanım alanı: CryptoLocker'ın ölçeklenmesi, fidye yazılımı tarihi ve uluslararası bozma operasyonu

S25 — Europol: Internet Organised Crime Threat Assessment 2016 — Malware

Internet Organised Crime Threat Assessment 2016 — Malware

• Tarih: 2016
• Kanıt düzeyi: A
• Kaynak türü: Uluslararası kolluk tehdit değerlendirmesi
• Bu rehberde kullanım alanı: 2015–2016 döneminde ransomware büyümesi ve hizmetleşme bağlamı

S26 — Paquet-Clouston ve diğerleri: Ransomware Payments in the Bitcoin Ecosystem

Ransomware Payments in the Bitcoin Ecosystem

• Tarih: akademik çalışma
• Kanıt düzeyi: B
• Kaynak türü: Akademik ekonomik ölçüm çalışması
• Bu rehberde kullanım alanı: Kripto para ödeme akışlarının araştırılabilirliği ve ölçüm belirsizliği

S27 — CISA, FBI ve çok uluslu ortaklar: #StopRansomware: LockBit 3.0

#StopRansomware: LockBit 3.0

• Tarih: 14 Haziran 2023
• Kanıt düzeyi: A
• Kaynak türü: Ortak siber güvenlik danışma belgesi
• Bu rehberde kullanım alanı: LockBit faaliyet modeli, sektörler ve savunma önlemleri

S28 — U.S. Department of Justice: Fact Sheet: CCIPS Enforcement Actions to Combat Cybercrime

Fact Sheet: CCIPS Enforcement Actions to Combat Cybercrime

• Tarih: güncel derleme
• Kanıt düzeyi: A
• Kaynak türü: Yargı ve bozma operasyonu kaydı
• Bu rehberde kullanım alanı: LockBit ve diğer gruplara yönelik uluslararası uygulama eylemleri

S29 — CISA, FBI, NSA ve U.S. Secret Service: Conti Ransomware

Conti Ransomware

• Tarih: 22 Eylül 2021
• Kanıt düzeyi: A
• Kaynak türü: Ortak siber güvenlik danışma belgesi
• Bu rehberde kullanım alanı: Conti faaliyetleri, tespit ve azaltım önerileri

S30 — CISA, FBI ve HHS: #StopRansomware: ALPHV Blackcat

#StopRansomware: ALPHV Blackcat

• Tarih: 19 Aralık 2023; Şubat 2024 güncellemesi
• Kanıt düzeyi: A
• Kaynak türü: Ortak siber güvenlik danışma belgesi
• Bu rehberde kullanım alanı: ALPHV/BlackCat faaliyetleri, sağlık sektörü riski ve azaltımlar

S31 — CISA ve FBI: #StopRansomware: CL0P Ransomware Gang Exploits MOVEit Vulnerability

#StopRansomware: CL0P Ransomware Gang Exploits MOVEit Vulnerability

• Tarih: 7 Haziran 2023
• Kanıt düzeyi: A
• Kaynak türü: Ortak siber güvenlik danışma belgesi
• Bu rehberde kullanım alanı: Cl0p, MOVEit kitlesel veri hırsızlığı ve tedarik zinciri riski

S32 — CISA, FBI, EC3 ve NCSC-NL: #StopRansomware: Akira Ransomware

#StopRansomware: Akira Ransomware

• Tarih: 18 Nisan 2024
• Kanıt düzeyi: A
• Kaynak türü: Çok uluslu siber güvenlik danışma belgesi
• Bu rehberde kullanım alanı: Akira hedefleri, faaliyet modeli, tespit ve azaltımlar

S33 — CISA, FBI, HHS ve MS-ISAC: #StopRansomware: Black Basta

#StopRansomware: Black Basta

• Tarih: 10 Mayıs 2024
• Kanıt düzeyi: A
• Kaynak türü: Ortak siber güvenlik danışma belgesi
• Bu rehberde kullanım alanı: Black Basta faaliyetleri, sağlık sektörü önceliği ve savunma

S34 — CISA, FBI ve Australian Signals Directorate: #StopRansomware: Play Ransomware

#StopRansomware: Play Ransomware

• Tarih: 18 Aralık 2023; 4 Haziran 2025 güncellemesi
• Kanıt düzeyi: A
• Kaynak türü: Çok uluslu siber güvenlik danışma belgesi
• Bu rehberde kullanım alanı: Play'in güncel faaliyetleri, yaklaşık etkilenen kuruluş sayısı ve azaltımlar

S35 — CISA, FBI ve MS-ISAC: #StopRansomware: Medusa Ransomware

#StopRansomware: Medusa Ransomware

• Tarih: 12 Mart 2025
• Kanıt düzeyi: A
• Kaynak türü: Ortak siber güvenlik danışma belgesi
• Bu rehberde kullanım alanı: Medusa'nın faaliyet modeli, kritik sektörler ve savunma

S36 — Centre for Cybersecurity Belgium (CCB): Threat Intelligence Report: DragonForce

Threat Intelligence Report: DragonForce

• Tarih: 20 Mayıs 2026
• Kanıt düzeyi: A
• Kaynak türü: Ulusal tehdit istihbaratı raporu
• Bu rehberde kullanım alanı: DragonForce'un 2026 RaaS yapısı, hedefleri, büyümesi ve savunma önerileri

S37 — U.S. Department of Justice: Sodinokibi/REvil Affiliate Sentenced for Role in $700M Ransomware Scheme

Sodinokibi/REvil Affiliate Sentenced for Role in $700M Ransomware Scheme

• Tarih: 1 Mayıs 2024
• Kanıt düzeyi: A
• Kaynak türü: Yargı kaydı
• Bu rehberde kullanım alanı: REvil bağlı kuruluş modeli, faaliyet dönemi ve kovuşturma

S38 — CISA, FBI, HHS ve MS-ISAC: #StopRansomware: RansomHub Ransomware

#StopRansomware: RansomHub Ransomware

• Tarih: 29 Ağustos 2024
• Kanıt düzeyi: A
• Kaynak türü: Ortak siber güvenlik danışma belgesi
• Bu rehberde kullanım alanı: RansomHub hedefleri, bağlı kuruluş ekosistemi ve azaltımlar

S39 — CISA, FBI, HHS ve MS-ISAC: #StopRansomware: Interlock

#StopRansomware: Interlock

• Tarih: 22 Temmuz 2025
• Kanıt düzeyi: A
• Kaynak türü: Ortak siber güvenlik danışma belgesi
• Bu rehberde kullanım alanı: Interlock'un 2024–2025 faaliyetleri ve savunma önerileri

S40 — U.S. Government Accountability Office (GAO): Colonial Pipeline Cyberattack Highlights Need for Better Preparedness

Colonial Pipeline Cyberattack Highlights Need for Better Preparedness

• Tarih: 18 Mayıs 2021
• Kanıt düzeyi: A
• Kaynak türü: Federal denetim kurumu vaka kaydı
• Bu rehberde kullanım alanı: Colonial Pipeline olay akışı, operasyonel etki ve hazırlık dersi

S41 — U.S. Department of Justice: Department of Justice Seizes $2.3 Million in Cryptocurrency Paid to DarkSide

Department of Justice Seizes $2.3 Million in Cryptocurrency Paid to DarkSide

• Tarih: 7 Haziran 2021
• Kanıt düzeyi: A
• Kaynak türü: Yargı ve varlık kurtarma kaydı
• Bu rehberde kullanım alanı: Colonial fidye ödemesi, DarkSide bağlantısı ve kısmi varlık kurtarma

S42 — Federal Bureau of Investigation (FBI): FBI Statement on JBS Cyberattack

FBI Statement on JBS Cyberattack

• Tarih: 2 Haziran 2021
• Kanıt düzeyi: A
• Kaynak türü: Resmî fail atfı
• Bu rehberde kullanım alanı: JBS olayının REvil/Sodinokibi'ye atfı

S43 — JBS USA: Cyberattack Media Statement

Cyberattack Media Statement

• Tarih: 9 Haziran 2021
• Kanıt düzeyi: A
• Kaynak türü: Mağdur kurumun birincil açıklaması
• Bu rehberde kullanım alanı: Olay etkisi ve 11 milyon ABD doları ödeme beyanı

S44 — Kaseya: Kaseya Responds Swiftly to Sophisticated Cyberattack

Kaseya Responds Swiftly to Sophisticated Cyberattack

• Tarih: 2021
• Kanıt düzeyi: A
• Kaynak türü: Mağdur/tedarikçi birincil açıklaması
• Bu rehberde kullanım alanı: VSA tedarik zinciri olayı ve doğrudan müşteri kapsamı

S45 — U.S. Department of Justice: REvil Ransomware Arrest and Seizures — Kaseya Case

REvil Ransomware Arrest and Seizures — Kaseya Case

• Tarih: 8 Kasım 2021
• Kanıt düzeyi: A
• Kaynak türü: Yargı ve kolluk açıklaması
• Bu rehberde kullanım alanı: Kaseya olayında REvil bağlantısı, bağlı kuruluş ve uluslararası soruşturma

S46 — MGM Resorts International / U.S. Securities and Exchange Commission: Form 8-K — September 2023 Cybersecurity Issue

Form 8-K — September 2023 Cybersecurity Issue

• Tarih: 5 Ekim 2023
• Kanıt düzeyi: A
• Kaynak türü: Düzenleyici kurum bildirimi
• Bu rehberde kullanım alanı: MGM operasyonel kesinti ve yaklaşık finansal etki

S47 — Caesars Entertainment / U.S. Securities and Exchange Commission: Form 8-K — Cybersecurity Incident

Form 8-K — Cybersecurity Incident

• Tarih: 14 Eylül 2023
• Kanıt düzeyi: A
• Kaynak türü: Düzenleyici kurum bildirimi
• Bu rehberde kullanım alanı: Caesars sosyal mühendislik, veri sızıntısı ve kamuya açıklama sınırları

S48 — U.S. Department of Health and Human Services (HHS): Change Healthcare Cybersecurity Incident Frequently Asked Questions

Change Healthcare Cybersecurity Incident Frequently Asked Questions

• Tarih: güncellenen resmî kaynak
• Kanıt düzeyi: A
• Kaynak türü: Federal sağlık düzenleyicisi kaydı
• Bu rehberde kullanım alanı: Change Healthcare olayı, HIPAA kapsamı ve bildirim sorumlulukları

S49 — UnitedHealth Group / U.S. Securities and Exchange Commission: 2024 Form 10-K

2024 Form 10-K

• Tarih: 27 Şubat 2025
• Kanıt düzeyi: A
• Kaynak türü: Denetlenmiş/düzenleyici mali bildirim
• Bu rehberde kullanım alanı: Change Healthcare doğrudan müdahale ve iş kesintisi maliyetleri

S50 — U.S. Senate Committee on Finance: Responses for Questions for the Record to Andrew Witty

Responses for Questions for the Record to Andrew Witty

• Tarih: 2024
• Kanıt düzeyi: A
• Kaynak türü: Kongre gözetim kaydı
• Bu rehberde kullanım alanı: Change Healthcare ilk erişim, MFA eksikliği, hizmet ve kredi desteği ayrıntıları

S51 — Sonic Automotive / U.S. Securities and Exchange Commission: Form 10-Q — CDK Global Incident Impact

Form 10-Q — CDK Global Incident Impact

• Tarih: 30 Haziran 2024 dönemi
• Kanıt düzeyi: A
• Kaynak türü: Düzenleyici mali bildirim
• Bu rehberde kullanım alanı: CDK kesintisinin bir otomotiv grubundaki yaklaşık mali etkisi

S52 — AutoNation / U.S. Securities and Exchange Commission: Form 10-Q — CDK Global Service Outage

Form 10-Q — CDK Global Service Outage

• Tarih: 30 Haziran 2024 dönemi
• Kanıt düzeyi: A
• Kaynak türü: Düzenleyici mali bildirim
• Bu rehberde kullanım alanı: CDK kesintisinin bayi operasyonları ve hisse başı sonuç etkisi

S53 — U.S. Office of the Director of National Intelligence: Worldwide Ransomware 2024

Worldwide Ransomware 2024

• Tarih: 2025
• Kanıt düzeyi: A
• Kaynak türü: Ulusal istihbarat değerlendirmesi
• Bu rehberde kullanım alanı: CDK/BlackSuit bağlamı ve dünya çapındaki 2024 ransomware görünümü

S54 — NHS England: Synnovis Cyber Incident — Questions and Answers

Synnovis Cyber Incident — Questions and Answers

• Tarih: 10 Kasım 2025 güncellemesi
• Kanıt düzeyi: A
• Kaynak türü: Ulusal sağlık sistemi vaka kaydı
• Bu rehberde kullanım alanı: Synnovis olay zaman çizelgesi, ertelenen hizmetler, veri ve klinik etkiler

S55 — UK Parliament / Department of Health and Social Care: Synnovis Cyber Incident — Written Statement HCWS1046

Synnovis Cyber Incident — Written Statement HCWS1046

• Tarih: 12 Kasım 2025
• Kanıt düzeyi: A
• Kaynak türü: Parlamento ve hükûmet açıklaması
• Bu rehberde kullanım alanı: Synnovis maliyet, hizmet toparlanması ve kamu sorumluluğu

S56 — World Bank: Costa Rica Cybersecurity Capacity and Ransomware Impact Assessment

Costa Rica Cybersecurity Capacity and Ransomware Impact Assessment

• Tarih: 2024
• Kanıt düzeyi: A
• Kaynak türü: Çok taraflı kalkınma kurumu raporu
• Bu rehberde kullanım alanı: Costa Rica kamu olayı, kurum kapsamı, süre ve tahmini ekonomik zarar

S57 — International Monetary Fund (IMF): Costa Rica: 2022 Article IV Consultation and Country Report

Costa Rica: 2022 Article IV Consultation and Country Report

• Tarih: 2022
• Kanıt düzeyi: A
• Kaynak türü: Çok taraflı kurum ülke raporu
• Bu rehberde kullanım alanı: Costa Rica kamu hizmetleri ve makroekonomik bağlam

S58 — U.S. Department of Justice: Coordinated Disruption Actions Against BlackSuit (Royal) Ransomware Operations

Coordinated Disruption Actions Against BlackSuit (Royal) Ransomware Operations

• Tarih: 11 Ağustos 2025
• Kanıt düzeyi: A
• Kaynak türü: Yargı ve uluslararası bozma operasyonu kaydı
• Bu rehberde kullanım alanı: BlackSuit/Royal altyapı bozma eylemi ve kritik altyapı etkisi

S59 — Cybersecurity and Infrastructure Security Agency (CISA): Cross-Sector Cybersecurity Performance Goals

Cross-Sector Cybersecurity Performance Goals

• Tarih: güncel kaynak
• Kanıt düzeyi: A
• Kaynak türü: Asgari siber güvenlik performans hedefleri
• Bu rehberde kullanım alanı: RaaS'a karşı ölçülebilir temel kontrol tabanı

S60 — U.S. Department of Justice: Two Americans Plead Guilty to Targeting Victims Using ALPHV BlackCat Ransomware

Two Americans Plead Guilty to Targeting Victims Using ALPHV BlackCat Ransomware

• Tarih: 30 Aralık 2025
• Kanıt düzeyi: A
• Kaynak türü: Yargı kaydı
• Bu rehberde kullanım alanı: ALPHV bağlı kuruluş gelir paylaşımı ve sorumluluk modelinin doğrulanması

S61 — Cybersecurity and Infrastructure Security Agency (CISA): Scattered Spider

Scattered Spider

• Tarih: 16 Kasım 2023; 2025 güncellemeleri
• Kanıt düzeyi: A
• Kaynak türü: Ortak siber güvenlik danışma belgesi
• Bu rehberde kullanım alanı: Yardım masası sosyal mühendisliği, kimlik kontrolleri ve Las Vegas vakaları bağlamı

S62 — U.S. Department of Justice: Qakbot Infrastructure and Ransomware Ecosystem Court Records

Qakbot Infrastructure and Ransomware Ecosystem Court Records

• Tarih: 2025
• Kanıt düzeyi: A
• Kaynak türü: İddianame ve yargı kaydı
• Bu rehberde kullanım alanı: Erişim ekosistemi ile Black Basta, Conti, REvil ve diğer ransomware aktörleri arasındaki iş bölümü

S63 — Oz, Aris ve diğerleri: A Comprehensive Survey of Ransomware: Evolution, Taxonomy and Defense

A Comprehensive Survey of Ransomware: Evolution, Taxonomy and Defense

• Tarih: 2021
• Kanıt düzeyi: B
• Kaynak türü: Akademik tarih ve sınıflandırma taraması
• Bu rehberde kullanım alanı: AIDS/PC Cyborg, erken ransomware tarihi ve 2015–2016 hizmetleşme örnekleri