Olay Müdahalesi Nedir? NIST SP 800-61 ile Dört Aşamalı Süreç

Bir saldırı fark edildiğinde en büyük düşman çoğu zaman saldırgan değil, kurumun içindeki kaostur. Kim karar verecek, hangi sistem kapanacak, müşteriye ne zaman haber verilecek? Bu yazıda olay müdahalesinin mantığını, NIST SP 800-61'in eski ve yeni modelini ve örnek bir fidye yazılımı olayını adım adım anlatıyoruz.

Olay müdahalesi nedir?

Olay müdahalesinin nasıl yürüyeceği, olay başlamadan çok önce belirlenmelidir. Yoksa ekip saldırganla değil, kendi kararsızlığıyla uğraşır. Önceden yazılmış bir plan olmadığında kritik sorular olay sırasında panikle cevaplanır ve bu hataya açık bir zemin yaratır.

Bu alanda en yaygın başvuru kaynağı, ABD Ulusal Standartlar ve Teknoloji Enstitüsü'nün (NIST) SP 800-61 yayınıdır. Yayının 2012 tarihli 2. revizyonu olay müdahalesini dört aşamalı bir döngü olarak anlatır. Bu model bugün de eğitimlerde ve sertifika sınavlarında yaygın olarak öğretilir. Nisan 2025'te yayımlanan 3. revizyon ise olay müdahalesini NIST Siber Güvenlik Çerçevesi (CSF) 2.0'ın altı işlevine bağladı.

Çerçeve bir tarif kitabı değildir. Her kurumun kendi sistemlerine göre uyarlaması gereken bir iskelettir. İskeletin kendisi evrensel olduğu için SOC ekipleri, tehdit istihbaratı uzmanları ve yöneticiler ortak bir dilde konuşur. Türkiye'deki kurumlar için bu çerçeve yerel düzenlemelerle çelişmez, onları tamamlar. Sektöre özgü bildirim yükümlülükleri olsa bile NIST'in yapısı onları zamanında ve doğru sırayla yerine getirmek için sağlam bir iskelet sunar.

Rev. 2 ile Rev. 3 arasındaki fark

Rev. 2 yazıldığında olaylar görece seyrekti ve çoğu bir iki günde kapanıyordu. Bu yüzden olay müdahalesi ayrı bir ekibin yürüttüğü, döngü şeklinde bir faaliyet olarak çizildi. Rev. 3'e göre bugün olaylar sık, geniş ve karmaşık. Toparlanma haftalar ya da aylar sürebiliyor. Bu yüzden müdahale, kurumun bütün siber risk yönetimine yayılmalı ve alınan dersler olay bitmeden paylaşılmalı.

Aşağıdaki tablo, NIST'in Rev. 3'te verdiği eşlemeyi temel alıyor.

NIST kurumların kendilerine en uygun modeli seçebileceğini de açıkça yazar. Büyük ve teknolojiye bağımlı kurumlar sürekli iyileştirmeyi öne çıkaran yeni modelden daha çok yararlanır. Küçük bir ekip için dört aşamalı model hâlâ anlaşılır bir başlangıçtır.

Neden önemli?

Bir ihlalin fark edilmesiyle kapatılması arasında geçen süre, toplam zararı doğrudan belirler. Fidye yazılımı bir dosya sunucusuna sızdığında ilk saatlerdeki hız, kaybedilecek veriyi ve kesinti süresini belirler. Plansız kurumlarda "sistemi kapat mı, açık mı bırak, delil topla mı" gibi kararlar anlık ve eksik bilgiyle alınır.

Düzenleyici yükümlülükler de olay müdahalesini zorunlu kılar. Birçok sektörde bir veri ihlalinden sonra belirli sürede bildirim gerekir. Türkiye'de kişisel veri ihlallerinde bu süre 72 saattir. Yapılandırılmış bir süreç hem teknik müdahaleyi hem bildirimi zamanında yapmayı kolaylaştırır.

Olay müdahalesi yalnız büyük kurumların konusu değildir. Küçük bir işletme aynı riskle, çoğu zaman daha az kaynakla karşı karşıyadır. Bu yüzden en azından temel bir planın yazılı olması, olay anında saatlerce süren belirsizliği önler.

Olay müdahalesi nasıl çalışır?

Rev. 2'nin dört aşaması, müdahalenin sırasını anlamak için hâlâ en açık anlatımdır:

• Hazırlık: Olaydan önce yapılan her şeydir. Roller belirlenir, iletişim planı yazılır, log toplama, adli imaj alma ve izole ağ bölümü gibi araçlar hazır tutulur.
• Tespit ve analiz: Bir SOC alarmı, kullanıcı şikâyeti ya da dış bildirimle olay fark edilir. Kapsam, etkilenen sistemler ve saldırganın yöntemi analiz edilir. Bu analiz çoğunlukla adli bilişim tekniklerinden yararlanır.
• Sınırlama, yok etme, kurtarma: Önce yayılma durdurulur, sonra saldırganın bıraktığı kalıcılık izleri temizlenir, en son sistemler güvenle normale döner.
• Olay sonrası faaliyet: Ekip ne olduğunu, neyin işe yaradığını ve neyin eksik kaldığını değerlendirir. En sık atlanan ama hazırlığı en çok güçlendiren adımdır.

Her aşamanın bir çıktısı vardır ve bir sonrakine girdi olur. Hazırlığın çıktısı iletişim planı ve araç listesidir. Tespit ve analizin çıktısı olayın zaman çizelgesidir. Sınırlama ve kurtarmanın çıktısı temizlenmiş ve doğrulanmış bir sistemdir. Olay sonrası faaliyetin çıktısı güncellenmiş bir plan ve yeni tespit kurallarıdır.

Sınırlama tek bir hamle değildir. Kısa vadeli sınırlama yayılmayı hemen durdurur, örneğin etkilenen sistemi ağdan ayırır. Uzun vadeli sınırlama ise iş sürekliliğini bozmadan saldırganın hareket alanını daraltır. Kritik bir üretim sistemini hemen kapatmak her zaman mümkün değildir. Bu kararı teknik ekip ile iş birimi birlikte verir.

Olay türleri farklı yaklaşım ister

Her olay aynı biçimde ilerlemez. Fidye yazılımında öncelik, şifreleme yayılmadan önce durdurmaktır. Veri sızıntısında öncelik hangi verinin ne zaman ve nereye gittiğini netleştirmektir, çünkü bu bilgi yasal bildirimi de belirler. Hizmet dışı bırakma saldırısında ise öncelik erişilebilirliği korurken saldırı trafiğini süzmektir. Bu yüzden ekipler tek bir tarifle değil, olay türüne göre yazılmış playbook'larla çalışır.

Somut örnek: Altay Kargo'da fidye yazılımı olayı

Altay Kargo'nun muhasebe sunucusunda bir sabah dosya uzantıları değişmiş ve bir fidye notu bırakılmış olsun. SOC ekibi hazırlıkta yazılan planı devreye sokar. İlk adım etkilenen sunucuyu ağdan ayırmaktır. Bu, sınırlamanın ilk hamlesidir. Ekip aynı anda etkilenmemiş yedekleri kontrol eder ve saldırının hangi hesapla başladığını anlamak için giriş loglarına bakar.

Analizde saldırının üç gün önce bir çalışanın e-postasındaki zararlı bir ekle başladığı ortaya çıkar. Yok etme aşamasında bu erişim noktası kapatılır ve saldırganın bıraktığı arka kapılar temizlenir. Kurtarmada sistemler temiz yedekten geri yüklenir. Olay sonrası toplantıda ekip, e-posta süzgecinin bu eki neden yakalamadığını sorgular ve boşluğu kapatacak bir kural ekler.

Toplantıda bir bulgu daha çıkar: yedekler üç haftadır geri yükleme testinden geçmemiştir. Kurtarma sırasında bir yedeğin bozuk olduğu anlaşılır ve bir önceki yedeğe dönülür, bu da süreyi birkaç saat uzatır. Bu bulgu hazırlığa geri döner. Altay Kargo artık yedeklerini ayda bir geri yükleyerek sınar. Rev. 3'ün vurguladığı sürekli iyileştirme tam olarak budur.

Bir olayı baştan sona kendin yönetmek istersen akademideki Olayı Kapat labı bir olay üzerinde makineyi sınırlamanı, delil zincirini bozmadan kanıt toplamanı ve adımları doğru sırayla kapatmanı ister.

Araçlar ve kariyer bağlantısı

Olay müdahale ekiplerinin kullandığı başlıca araçlar şunlardır:

• SIEM ve log analiz araçları: olayın zaman çizelgesini çıkarmak için.
• Adli imaj alma araçları: disk ve bellek verisini bozmadan kaydetmek için.
• Ağ ayırma ve bölütleme araçları: yayılmayı durdurmak için.
• İletişim ve belgeleme platformları: alınan her kararı kayda geçirmek için. Bu kayıtlar hem hukuki hem teknik açıdan kritiktir.

Araçlar kadar önemli olan, önceden belirlenmiş bir iletişim planıdır. Kimin karar vereceği, kimin müşteriyle konuşacağı ve kimin teknik ayrıntıyı yöneteceği net değilse en iyi araç bile koordinasyonsuzluğu önleyemez.

Olay müdahalesi, Mavi Takım kariyerinin en kritik uzmanlıklarından biridir. SOC analistliğinden bu role geçiş doğal bir ilerlemedir. SOC analisti alarmı doğru sınıflandırmayı öğrenir, olay müdahale uzmanı ise alarmın büyüdüğü noktadan itibaren süreci uçtan uca yönetir. Mülakatlarda adaylara sık sık bir olay senaryosunu nasıl yöneteceği sorulur. Mülakat hazırlığı sayfası bu soruları role göre topluyor.

Nereden başlamalı?

Olay müdahalesine geçmeden önce SOC analistliği ve temel log analizi becerisi gerekir. Bu alan sıfırdan değil, var olan bir teknik temelin üstüne kurulur. NIST SP 800-61 Rev. 3'ü okumak yeni modeli anlamak için iyi bir başlangıçtır. Rev. 2 ise dört aşamalı döngüyü öğrenmek ve sınavlara hazırlanmak için hâlâ işe yarar.

Akademide Hazırlık, Tespit ve sınırlama ve Raporlama ve alınan dersler dersleri bu yazının uygulamalı karşılığıdır. Saha görevlerindeki olay müdahale senaryoları da kalıcılık izi, şüpheli servis ve uçucu kanıt toplama gibi işleri tarayıcıdaki terminalde yaptırır.

Öğrenirken edinebileceğin en değerli alışkanlık, her adımı yazmaktır. Gerçek bir olayda "kim, ne zaman, hangi kararı verdi" sorusu hem teknik değerlendirme hem de hukuki süreç için kritik olur.

Kaynaklar

• NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management (Nisan 2025)
• NIST SP 800-61 Rev. 2: Computer Security Incident Handling Guide (2012, yerini Rev. 3 aldı)
• NIST Cybersecurity Framework 2.0
• FIRST: olay müdahale standartları ve çerçeveleri