Bir olay müdahale planı, en çok cuma akşamı saat 18.40’ta işe yarar: sistem yöneticisi üretim veritabanı sunucusunda tanımadığı bir hizmetin çalıştığını fark eder, güvenlik ekibinden kimseye ulaşamaz, sunucuyu kapatsa mı yoksa beklese mi bilemez. Sunucuyu kapatır. Bellekteki tüm kanıt kaybolur, saldırganın hangi hesabı kullandığı bir daha öğrenilemez ve kurum ertesi hafta aynı yöntemle yeniden erişilir. Burada eksik olan araç değil, o an kimin karar vereceğinin yazılı olmamasıdır.

İyi bir plan, kriz anında düşünmeyi değil uygulamayı gerektirir. Kim aranacak, hangi eşikte yönetim bilgilendirilecek, hangi sistem izole edilebilir, hangi kanıt kimin onayıyla toplanacak — bunların tamamı olaydan önce kararlaştırılmış olmalıdır. Aşağıda planın içermesi gereken roller, şiddet seviyeleri, adım sırası ve planı kâğıt üstünde kalmaktan kurtaran doğrulama yöntemleri ele alınıyor.

Planın çözdüğü asıl sorun: yetki ve karar boşluğu

Olay anında üç tür gecikme yaşanır. Birincisi fark etme gecikmesi, ikincisi ulaşma gecikmesi, üçüncüsü ve genellikle en pahalısı karar gecikmesidir. Fabrikanın üretim hattını durdurma yetkisi kimde? Müşteriye erişimi kesme kararını kim verir? Bu sorular olay sırasında tartışılırsa saldırgan kazanır.

Bu nedenle plan, teknik prosedürden önce bir yetki matrisi olmalıdır. Her karar tipi için tek bir sahip, bir yedek ve bir zaman sınırı tanımlanır: “Yedek karar verici 15 dakika içinde yanıt vermezse yetki bir üst seviyeye geçer” gibi. Karar boşluğunu kapatan bu tür kurallar, olgun kurumların planlarını ayıran en belirgin unsurdur.

Olay müdahale planındaki çekirdek roller

Rol, unvan değildir. Aynı kişi küçük kurumda iki rolü üstlenebilir, ama roller adlandırılmadan sorumluluk dağıtılamaz.

• Olay komutanı (incident commander): Tek karar merkezi. Teknik işi yapmaz, kimin ne yaptığını ve durumun genel resmini yönetir.
• Teknik müdahale lideri: Sınırlandırma ve kök kazıma adımlarını yürütür, uç nokta ve ağ ekipleriyle koordinasyonu sağlar.
• Adli inceleme sorumlusu: Kanıtın bütünlüğünü korur, imaj alma ve kayıt zinciri (chain of custody) sürecini yönetir.
• İletişim sorumlusu: İç duyurular, müşteri bilgilendirmesi ve gerekiyorsa basın metni tek elden çıkar.
• Hukuk ve uyum temsilcisi: Bildirim yükümlülüklerini, sözleşmesel taahhütleri ve delil kabul edilebilirliğini değerlendirir.
• Kayıt tutucu: Zaman damgalı olay günlüğünü tutar; bu kayıt hem raporun hem de olası hukuki sürecin temelidir.

Rollerin kurum yapısına oturtulması, özellikle güvenlik ekibi küçük olan şirketlerde dışarıdan destekle daha sağlıklı yürür; kurumsal siber güvenlik danışmanlığı kapsamında yapılan bir rol-yetki çalışması, kâğıt üstünde var olan ama gerçekte sahibi bulunmayan görevleri açığa çıkarır.

Şiddet seviyeleri ve tırmandırma eşikleri nasıl tanımlanır

Her olay aynı tepkiyi hak etmez. Seviyeleri belirsiz bırakmak iki yönlü zarar verir: küçük olaylar için gece yarısı yönetim toplanır, büyük olaylar ise “önce inceleyelim” denerek geciktirilir. Seviye tanımı, sistemin kritikliği ile etkinin türünü birlikte ele almalıdır.

Eşikler yazılırken “kritik sistem” tanımının envanterde karşılığı olmalıdır. Hangi sunucunun S1 kapsamına girdiği olay anında yorumlanacaksa seviye sistemi işlevsizdir.

Müdahale adımları: hazırlıktan olay sonrası derse

NIST SP 800-61 yaşam döngüsü, Türkiye’deki kurumların çoğunda uyarlanabilir bir iskelet sunar. Aşağıdaki sıra, bu iskeletin sahadaki karşılığıdır.

1. Hazırlık. İletişim listesi, yetki matrisi, izole ağ segmenti, temiz imaj deposu, çevrimdışı yedek erişimi ve olay kayıt şablonu önceden hazır olur.
2. Tespit ve doğrulama. Alarm bir olaya dönüşmeden önce doğrulanır: hangi varlık, hangi kimlik, hangi zaman aralığı? Doğrulanmamış alarmla ekip seferber edilmez.
3. Kapsam belirleme. Etkilenen varlıkların tam listesi çıkarılır. Bu adım atlandığında sınırlandırma eksik kalır ve saldırgan ikinci dayanak noktasından geri döner.
4. Kanıt koruma. İzolasyon öncesi uçucu veri (bellek, aktif bağlantılar, çalışan süreçler) toplanır. Sunucuyu kapatmak, bu adımdan önce yapılabilecek en zararlı hamledir.
5. Sınırlandırma. Ağ seviyesinde izolasyon, hesap askıya alma, oturum ve belirteç iptali. Kısa vadeli sınırlandırma ile kalıcı çözüm ayrı ele alınır.
6. Kök kazıma. Zararlının kalıcılık mekanizmaları, açılan hesaplar, değiştirilen görevler ve arka kapılar temizlenir; giriş noktası kapatılır.
7. Kurtarma. Sistemler kontrollü biçimde geri alınır ve artırılmış izleme altında tutulur. Geri dönen sistem, saldırganın ilk hedefidir.
8. Olay sonrası değerlendirme. Zaman çizelgesi, kök neden, tespit boşlukları ve eylem maddeleri sahibiyle birlikte kayda geçer.

İletişim planı: kim kime, hangi kanaldan haber verir

Kurumsal e-posta ve mesajlaşma sistemi olayın parçası olabilir. Saldırganın posta kutusunu okuduğu bir vakada müdahale planını e-postayla paylaşmak, planı saldırgana teslim etmek demektir.

• Ana kanal dışında bant dışı (out-of-band) bir iletişim yöntemi tanımlayın ve iletişim bilgilerini çevrimdışı da saklayın.
• İç bilgilendirme metinlerini şablonlaştırın: ne biliniyor, ne bilinmiyor, çalışanlardan ne isteniyor.
• Müşteri ve tedarikçi bildirim eşiklerini sözleşmelerdeki taahhüt sürelerine göre önceden belirleyin.
• Tek sözcü ilkesini uygulayın; farklı ekiplerden çıkan çelişkili açıklamalar itibar kaybının en hızlı yoludur.

KVKK ve uyum yükümlülükleri planın neresinde durur

Kişisel veri içeren bir ihlalde teknik müdahale ile hukuki süreç paralel yürür. KVKK kapsamında veri sorumlusu, ihlali öğrendiği tarihten itibaren gecikmeksizin ve makul olan en kısa sürede Kişisel Verileri Koruma Kurulu’na bildirimde bulunur; Kurul’un belirlediği çerçevede bu süre 72 saat olarak uygulanır ve ilgili kişilere de bildirim yapılması gerekir.

Planın hukuk bölümü şu üç soruyu açıkça yanıtlamalıdır: “İhlali öğrenme anı” hangi kayıtla belgelenecek, bildirim metnini kim hazırlayacak, hangi bilgiler bildirim anında bilinmiyorsa nasıl ifade edilecek. ISO 27001 kapsamında bir bilgi güvenliği yönetim sistemi işletiliyorsa olay kayıtları ve düzeltici faaliyetler zaten denetime tabi olduğundan, plan bu kayıtlarla uyumlu tutulmalıdır.

Planı kâğıttan çıkarmak: tatbikat ve gerçek koşulda doğrulama

Yazılıp klasöre kaldırılan plan, olay anında açılmaz. Doğrulamanın iki katmanı vardır. Birincisi masa başı tatbikattır: yöneticiler ve teknik ekip bir senaryo üzerinden kararları sözlü olarak yürütür, sürtünme noktaları not edilir. Bu, planın mantık hatalarını bulmanın en ucuz yoludur. Tatbikatta şu sürtünme noktaları not edilmelidir:

• Bir karar için kaç kişinin onayı arandı ve o onaylar kaç dakikada toplandı?
• İletişim listesindeki kaç kişiye ilk denemede ulaşılamadı?
• Hangi adımda “bunu kimin karara bağlayacağını bilmiyoruz” cümlesi kuruldu?
• Yedeklere, log platformuna veya izolasyon araçlarına erişimi olması gerekip de olmayan kim vardı?

İkinci katman gerçek koşulda sınamadır. Belirli sistemlerdeki zafiyetleri hedefleyen sızma testi genellikle bir-iki hafta sürer ve teknik bulgu listesi üretir; buna karşılık iki ila altı haftaya yayılan bir red team hizmeti, keşif, ilk erişim, yanal hareket (lateral movement) ve yetki yükseltme, hedef tamamlama ve raporlama aşamalarıyla planın kendisini test eder. Ekip alarmı gördü mü, olay komutanı devreye girdi mi, tırmandırma eşiği çalıştı mı, iletişim bant dışı kanaldan yürüdü mü? Bu sorulara verilen yanıtlar planın gerçek olgunluğunu gösterir.

Plan sağlığını ölçen göstergeler

• MTTD (ortalama tespit süresi): Saldırganın ilk eyleminden doğrulanmış tespite kadar geçen süre.
• MTTR (ortalama yanıt süresi): Doğrulamadan sınırlandırmanın tamamlanmasına kadar geçen süre.
• Tırmandırma doğruluğu: Doğru seviyede açılan olayların oranı; sürekli seviye düşürülüyorsa eşikler yanlış konumlanmıştır.
• Eylem maddesi kapanış oranı: Olay sonrası kararlaştırılan iyileştirmelerin süresinde tamamlanma yüzdesi.
• Tatbikat kapsama oranı: Yılda en az bir kez senaryoya dahil edilen kritik sistem oranı.

Sık sorulan sorular

Olay müdahale planı kaç sayfa olmalı?

Sayfa sayısı bir kalite ölçüsü değildir. Kriz anında kullanılacak bölümün tek sayfaya sığması gerekir: kimi arayacağım, ne yapmam yasak, hangi eşikte kimi bilgilendireceğim. Ayrıntılı prosedürler eki oluşturur; ana metin kısa ve uygulanabilir olmalıdır.

Küçük bir şirkette bu rollerin hepsi gerekli mi?

Roller gereklidir, ayrı kişiler değil. On kişilik bir şirkette olay komutanı ile iletişim sorumlusunu aynı kişi üstlenebilir. Kritik olan, kimin hangi şapkayı taktığının olaydan önce yazılı olması ve her rol için bir yedeğin tanımlanmasıdır.

Fidye yazılımı için ayrı bir plan mı yazmalıyız?

Ana planın içine senaryo eki olarak yazmak daha sürdürülebilirdir. Fidye yazılımı, veri sızdırma ve tedarikçi kaynaklı ihlal gibi senaryolar için ayrı karar ağaçları hazırlanır; ancak roller, tırmandırma eşikleri ve iletişim yapısı ortak kalır.

Planı ne sıklıkla güncellemeliyiz?

Takvime bağlı yılda bir gözden geçirme asgari koşuldur, ancak asıl tetikleyiciler olaylardır. Gerçek bir olaydan, tatbikattan, kritik bir sistem değişikliğinden veya organizasyon değişikliğinden sonra plan mutlaka güncellenir. Güncellenmeyen iletişim listesi, planın en sık rastlanan arızasıdır.

Müdahaleyi dışarıdan destekle yürütmek kanıt değerini etkiler mi?

Etkilemez; belirleyici olan yöntemdir. Toplama sırası, imaj bütünlüğü ve kayıt zinciri usulüne uygun yürütüldüğü sürece işi kimin yaptığı kanıtın kabul edilebilirliğini değiştirmez. Dış destek alınacaksa sözleşmenin olaydan önce hazır olması, kriz anındaki en büyük gecikmelerden birini ortadan kaldırır.

Sonuç

Olay müdahale planının değeri, içerdiği prosedür sayısında değil kriz anında sorulacak soruların kaçını önceden yanıtladığındadır. Rolleri adlandırılmış, şiddet seviyeleri envanterle eşleşmiş, iletişim kanalı bant dışına taşınmış ve en az bir kez gerçek koşulda sınanmış bir plan, aynı saldırıyı sekiz günlük bir felaketten üç saatlik bir olaya dönüştürür; bu dönüşümü sağlamayan her plan, yalnızca denetim klasöründe yer kaplar.

Bilgilendirme: Bu içerik genel bilgilendirme amaçlıdır; kurumunuzun risk profiline özel değerlendirme için uzman desteği alınmalıdır.