Oltalama Simülasyonu Nasıl Yapılır? Güveni Bozmadan Test Etmenin Yolları

Verizon Veri İhlali Araştırmaları Raporu'nun 2026 baskısına göre ihlallerin %62'sinde insan unsuru var. Oltalama simülasyonunun bugün her ciddi güvenlik programında standart bir kontrol olmasının sebebi bu tek rakam. Ama rakam ikinci bir gerçeği gizliyor: kötü kurgulanmış bir simülasyon programı ciddi zarar verebilir. Güveni aşındırır, olay bildirimlerini bastırır ve çalışanlara güvenlik ekibinin onları kandırmaya çalıştığını öğretir.

İki sonuç arasındaki farkı araç değil, programın tasarımı belirler. Bu rehber, davranışı değiştiren simülasyonları kırgınlık üreten simülasyonlardan ayıran uygulamaları anlatıyor; dayanağı da Verizon, KnowBe4 ve NIST'in bugünkü verilerinin gerçekten desteklediği şeyler.

Simülasyon doğru yapıldığında neden işe yarar?

İyi tasarlanmış simülasyon programlarının kanıtı güçlü. KnowBe4'ün 2026 sektörlere göre oltalama karşılaştırma raporu, 64.000 kurumda 14,8 milyon kullanıcıya gönderilen 42 milyon simüle oltalama e-postasına dayanıyor. Rapora göre eğitim almamış kurumlarda oltalamaya açıklık oranı başlangıçta %33,2; yani kabaca her üç çalışandan biri başlangıç testindeki e-postayla etkileşime giriyor. Eğitim ve simülasyon birlikte sürdürüldüğünde bu oran doksan günde %20,1'e, on iki ayda %4,2'ye iniyor.

Burada bilinçli olarak yayımlanmış oranları veriyoruz, bir "düşüş yüzdesi" başlığı değil. KnowBe4'ün aynı veriye ilişkin kendi özetleri birbirinden farklı düşüş rakamları verdi; oysa iki oranı herkes kendisi kontrol edebilir.

Bu verinin sizin için anlamı şu: tek seferlik bir test değil, süreklilik sonuç veriyor. Simülasyonu bir yıllık etkinlik olarak değil, bir ölçüm ve alıştırma döngüsü olarak kurmanız gerekiyor.

Bu döngünün en önemli çıktısı ise tıklama değil, bildirimdir. İki dakika içinde bildirilen bir oltalama e-postası, olay müdahalesine verilen bir avans demektir. Sessizce silinen ya da sessizce tıklanan bir e-posta ise hiçbir şey kazandırmaz. Program tasarımındaki her karar tek bir yöne itmeli: daha çok bildirim, daha hızlı bildirim.

Oltalama simülasyonunun amacı çalışanı hata yaparken yakalamak değildir. Amaç, şüpheli bir e-postayı bildirmeyi ekranı kilitlemek kadar alışılmış bir harekete dönüştürmektir.

Türkiye'deki bankalar için bu yalnızca iyi bir uygulama değil, düzenleyici bir beklenti de. BDDK'nın Bilgi Sistemleri Yönetmeliği m.19(4), güncel saldırı yöntemlerine göre sosyal mühendislik senaryolarıyla periyodik test ister ve testi geçemeyen çalışanlara ilave hedefli eğitim verilmesini şart koşar. Ayrıntıları finansal hizmetler sayfamızda ele alıyoruz.

Oltalama simülasyonu için sekiz ilke

1. İlk gönderimden önce hedefi tanımlayın

"Tıklamaları azaltmak" bir hedef değil, bir yan etkidir. Gerçekte neyi değiştirmeye çalıştığınızı yazın: ilk bildirime kadar geçen süre, e-postayı görmezden gelmek yerine bildiren çalışanların oranı, yüksek riskli ekiplerde tekrar tıklayan kişi sayısı. Bu hedefler ve temel kurallar için (ceza yok, kimse ifşa edilmez) üst yönetimin onayını alın. Böylece kıdemli biri tıkladığında program korunmuş olur. Ve kıdemli biri mutlaka tıklayacaktır.

2. Dürüst bir başlangıç ölçümü yapın

İlk kampanyayı herhangi bir duyuru ya da eğitimden önce, orta zorlukta bir şablonla ve kurumun tamamında yapın. Bu, elde edeceğiniz tek tarafsız ölçümdür ve ileride öne süreceğiniz her iyileşme iddiası buna dayanacaktır. Rakamlar daha iyi görünsün diye ilk testi yumuşatma isteğine direnin.

3. Her ay test edin, her şeyi rastgele yapın

Davranış zamanla zayıflar, kadro değişir. Gönderim saatlerinin rastgele dağıtıldığı, şablonların dönüşümlü kullanıldığı ve hedef grupların kademelendirildiği aylık bir düzen iki klasik hatayı önler: herkesin önceden tahmin etmeyi öğrendiği üç aylık "oltalama mevsimi" ve dakikalar içinde şirketin mesajlaşma grubunda ifşa olan tek seferlik toplu gönderim.

4. Zorluğu bilinçli olarak ayarlayın

Her simülasyon kolay yakalanıyorsa metrikleriniz sizi olduğunuzdan iyi gösterir. Her simülasyon ustalıkla hazırlanmış bir hedefli oltalama ise çalışanlar çaresizliği öğrenir. NIST Phish Scale, her şablonun tespit zorluğunu içerdiği ipuçlarına ve bağlama uygunluğuna göre tekrarlanabilir biçimde derecelendirmenizi sağlar. Böylece zorluk seviyelerini bilinçli olarak karıştırabilir ve tıklama oranlarını adil yorumlayabilirsiniz: zor bir şablonda %12 tıklama, bariz bir şablonda %4 tıklamadan daha iyi bir sonuçtur.

Somut bir örnek: "Hızlıkargo" adlı uydurma bir kargo firmasından, hizlikargo.example adresinden gelen ve "teslimat adresiniz eksik" diyen bir bildirim kolay bir şablondur; gönderen alan adı, genel hitap ve aciliyet ipucu bir aradadır. Aynı kargo bildiriminin, çalışanın gerçekten beklediği bir siparişle örtüşen ve şirket içi bir satın alma sürecini taklit eden versiyonu ise çok daha zordur. İkisinin sonucunu aynı terazide tartmak sizi yanıltır.

5. Tıklamayı asla cezalandırmayın

Uğruna direnilecek tepe budur. Simülasyonda başarısız olanların primini kesen, adını ifşa eden ya da işten çıkarmakla tehdit eden programlar hep aynı sonucu alır: bildirimler çöker, çalışanlar birbirini uyarır ve güvenlik ekibi gerçek bir olay sırasında en çok ihtiyaç duyduğu ilişkiyi kaybeder. Bireyleri koçlukla destekleyin, yalnızca süreklilik gösteren örüntülerde konuyu üst kademeye taşıyın ve bunların hepsini programın kurallarında açıkça yazın.

6. Yalnızca tıklamayı değil, bildirimi ölçün

Tıklama oranı oltalama simülasyonunun vitrin metriğidir. Gerçek dünyadaki dayanıklılığı öngören rakamlar bildirim oranı, bildirim/tıklama oranı ve e-postanın ulaşmasıyla ilk bildirim arasında geçen medyan süredir. Tıklama oranı %8 ama bildirim oranı %70 olan bir ekip, tıklama oranı %3 olan ama kimsenin hiçbir şey bildirmediği bir ekipten çok daha güvenlidir.

Bu metriklerin nasıl hesaplanıp raporlanacağını oltalama simülasyonu metrikleri yazımızda ayrıntılı olarak anlatıyoruz.

7. E-postanın ötesine geçin

Gerçek saldırganlar çoktan geçti. Sesli oltalama (vishing), SMS oltalama (smishing), QR kodlu tuzaklar (quishing) ve MFA yorgunluğu bildirimleri artık sıradan ilk erişim teknikleri. Yalnızca e-postayı test eden bir program dünün tehdit modelini ölçer. Dönüşümünüze SMS ve QR senaryolarını katın; güvenle simüle edemediğiniz kanallar için de simülasyonları senaryo eğitimiyle tamamlayın. Kanal karışımının ne kadar hızlı değiştiğini sosyal mühendislik istatistikleri derlememizde izliyoruz.

8. Organizasyon şemasına değil, riske göre gruplayın

Finans ödemeleri onaylar, yönetici asistanları takvimi ve seyahati yönetir, BT yöneticileri ayrıcalıklı erişimi elinde tutar. Her biri farklı tuzaklarla karşılaşır ve farklı senaryoları hak eder. Olgun programlar her çalışana rolüne, erişimine ve geçmiş simülasyon davranışına göre bir risk seviyesi atar, ardından senaryo zorluğunu ve sıklığını buna göre ayarlar. Human Risk Score (İnsan Risk Skoru) tam olarak bu sorunu çözmek için var: dağınık simülasyon sonuçlarını üzerinde işlem yapabileceğiniz kişi bazında bir risk sinyaline dönüştürür.

90 günlük başlangıç planı

1–15. gün: Temel. Program kurallarını yazın (hedefler, temel kurallar, cezasız yaklaşım), üst yönetimin onayını alın, oltalama bildirim düğmesini kurun ve duyurun. Çalışanların tek tıkla bildirim yapabileceği bir yol yoksa her şeyden önce bunu çözün.

16–30. gün: Başlangıç ölçümü. Önceden duyurulmamış başlangıç kampanyasını, zorluğu derecelendirilmiş orta seviye bir şablonla yapın. Tıklama oranını, bildirim oranını ve ilk bildirime kadar geçen süreyi kaydedin. Sonuçları kimsenin adını vermeden yönetime sunun.

31–60. gün: İlk eğitim döngüsü. Sürekli programı duyurun. Kısa ve role uygun eğitimler verin; bilginin ne kadar hızlı unutulduğunu gösteren araştırmalar, yıllık bir maratondan çok sık ve kısa oturumları destekliyor. İkinci kampanyayı dönüşümlü şablonlar ve rastgele gönderimlerle yapın.

61–90. gün: Rutine bağlama. Aylık düzene geçin. E-posta dışında bir senaryo ekleyin. Tekrar tıklayanlar için koçluk döngüsünü başlatın. Tıklama ve bildirim oranlarının eğilimini gösteren bir program panosu yayımlayın; toplu sonuçlar konusundaki şeffaflık, cezacı programların yıktığı güveni inşa eder.

91. günden itibaren program kendi kendini döndüren bir çarka dönüşür: simüle et, ölç, koçluk yap, zorluğu artır, tekrarla. NOUSEC'in oltalama simülasyonu bu işin mekaniğini otomatikleştirir: şablon dönüşümü, zorluk ayarı, kişi bazında zamanlama ve tıklama anında verilen anında eğitim. Böylece küçük bir güvenlik ekibi de kurumsal ölçekte bir program yürütebilir.

Programları batıran yaygın hatalar

Aynı başarısızlık örüntüleri tekrar tekrar karşımıza çıkıyor:

• herkesin önceden tahmin ettiği üç aylık aralıklarla test etmek;
• programı yalnızca tıklama oranıyla değerlendirmek;
• öğrenme yerine tepki üreten, duygusal açıdan ağır tuzaklar kullanmak (sahte ikramiye, sahte işten çıkarma duyurusu);
• üst yöneticileri testin dışında tutmak;
• simülasyonu bir ölçüm aracı değil, ürünün kendisi gibi görmek.

Oltalama, sahtecilik (spoofing) ve türevleri zaten yeterince gerçek bir tehdit; kurum içinde yapay bir öfke üretmeye gerek yok.

Bir oltalama simülasyonu programı, özünde büyük ölçekte yürütülen bir güven inşası çalışmasıdır. Net hedefler, dürüst ölçüm ve sıfır cezayla yürütüldüğünde, gerçek bir saldırı e-posta kutusuna düştüğü gün istediğiniz şey elinizde olur: daha az tıklama ve çok daha fazla bildirim.