Bu rehber, siber güvenlik akış şemasındaki yönetişim başlığını ve 01 ile 11 arasındaki bütün adımları açıklar. Rehber her yıl düzenli olarak risk değerlendirmesi sonucu güncellenir.
Amaç; kullanıcıları, cihazları, sunucuları, ağı, uygulamaları, bulut hizmetlerini ve verileri birlikte koruyan, bir saldırı belirtisi görüldüğünde de kontrollü müdahale ve güvenli kurtarma sağlayan bir süreç kurmaktır. Her bölüm, ilgili adımın neden gerekli olduğunu, nasıl uygulanacağını, kimin sorumluluk alacağını ve hangi kayıtlarla doğrulanacağını anlatır.
Risk koruma ve izleme
Şemanın ilk ana bölümü, olay yaşanmadan önce görünürlük ve dayanıklılık oluşturur. Envanter koruma kapsamını; risk değerlendirmesi öncelikleri; koruyucu kontroller savunmayı; izleme ise hem saldırı belirtilerini hem kontrol bozulmalarını ortaya çıkarır. Bu faaliyetler birlikte işletilmelidir. Yeni bir sunucu açıldığında envantere eklenmesi, riskinin değerlendirilmesi, güvenlik ayarlarının uygulanması ve loglarının takibe alınması aynı hizmet açılışının parçalarıdır.
Bu bölümün yönetim açısından sonucu, kritik hizmetlerin hangi risklerle çalıştığının ve kontrollerin hangi kanıtlarla doğrulandığının bilinmesidir. Teknik açıdan sonucu; sahipsiz varlıkların, gereksiz erişimlerin ve izleme boşluklarının azalmasıdır. Başarılı bir hazırlık bütün olayları ortadan kaldırmaz; olayın etkisini sınırlar, erken fark edilmesini ve gerekli bilgiye ulaşılmasını kolaylaştırır.
Olay müdahalesi ve kurtarma
Şemanın ikinci ana bölümü, şüphenin değerlendirilmesinden hizmetin kabul edilerek geri dönmesine kadar olay yönetimini açıklar. Doğrulama, zarar sınırlaması, kapsam analizi, tehdit giderme ve kurtarma aynı olayın birbirine bağlı çalışmalarıdır. Sınırlama sırasında bulunan yeni hesap analizi genişletebilir; analizde bulunan başka giriş yolu ek sınırlama gerektirebilir. Bu nedenle adımlar gerektiğinde tekrar edilir ve eş zamanlı ilerleyebilir.
Bu bölümdeki temel ayrım, erişimin geçici olarak kesilmesi ile sistemin güvenli hale getirilmesi arasındadır. İzole cihaz veya kapalı hesap kontrol altında olabilir, fakat hâlâ temizlenmesi gereken bileşenler bulunabilir. Güvenli geri dönüş, teknik test ve iş kabulüyle yapılır. Kapanış ise kalan görevleri sahiplenir ve olayda öğrenilenleri tekrar envanter, risk, koruma ve izleme düzenine aktarır.
Rehberin kullanım şekli
Önce yönetişim ile 01 ve 02 numaralı bölümler üzerinden neyin korunacağını ve hangi riskin öncelikli olduğunu belirleyin. Ardından 03 numaralı bölümdeki kontrolleri, 04 numaralı bölümdeki izleme düzenini ve 05 numaralı bölümdeki müdahale hazırlığını birlikte kurun. Şüpheli bir durum görüldüğünde 06 numaralı doğrulama adımını başlatın. Doğrulanan olaylarda 07, 08 ve 09 numaralı adımlar birbirini besleyerek yürür. Güvenlik ve işlev testleri yeterli kanıt sağladığında 10 numaralı kurtarmaya, sonrasında 11 numaralı kapanış ve iyileştirmeye geçin.
Şemanın üç karar noktası özellikle önemlidir. Şüpheli olay yoksa izleme sürer. Alarm doğrulanmazsa gerekçesi kayıt altına alınır; yanlış alarm veya henüz sonuçlandırılamamış şüphe ayrımı yapılır. Tehdit giderilmemişse veya testler başarısızsa sistem üretime açılmaz; analiz ve düzeltme tekrar edilir. Bilinmeyen bir sonucu otomatik olarak güvenli saymak, bu akışın mantığını bozar.
İçindekiler
01 Varlıkları ve verileri belirle
02 Riskleri değerlendir ve önceliklendir
03 Koruyucu kontrolleri uygula
06 Alarmı doğrula ve önceliklendir
08 Kapsamı ve kök nedeni analiz et
09 Tehdidi gider ve açıklığı kapat
10 Güvenli biçimde hizmete dön
Yönetişim tüm aşamalar boyunca
Amaç ve kapsam
Yönetişim, siber güvenlikte kararların kim tarafından, hangi önceliklerle ve hangi hesap verme düzeni içinde alınacağını belirler. Bir güvenlik ürününün satın alınması, o ürünün alarmlarını kimin inceleyeceği ve gerektiğinde hizmeti kimin durdurabileceği bilinmiyorsa yeterli değildir. Yönetişim; politika, görev dağılımı, bütçe, risk kabulü, tedarikçi ilişkileri ve iletişim kuralları üzerinden teknik çalışmaların sürdürülebilir olmasını sağlar.
Kapsama çalışanlar ve yöneticiler kadar dış hizmet sağlayıcılar, bakım firmaları, bulut işletmecileri, danışmanlar ve uzaktan erişen diğer taraflar da alınır. Bir tedarikçinin erişimi kurumun ağında sonuç doğuruyorsa, bu erişimin onaylanması, izlenmesi ve kaldırılması kurumun güvenlik yönetiminin parçasıdır. Bulut hizmetinde de veri, kimlik, yapılandırma ve altyapı sorumlulukları sözleşme ile teknik hizmet modeline göre açıkça ayrılmalıdır.
Uygulama adımları
1. İş hedeflerini ve kritik hizmetleri tanımlayın. Hangi hizmetin kesilmesi gelir, üretim, müşteri güveni veya çalışan güvenliği üzerinde ciddi etki yaratır? Yönetim bu etkiyi ve hangi risk düzeyini kabul edebileceğini açıklamalıdır. Teknik ekip, bu iş önceliklerine göre koruma ve kurtarma sırasını düzenler.
2. Güvenlik politikasını onaylayın. Kimlik ve erişim, uzaktan çalışma, veri paylaşımı, taşınabilir cihazlar, güncelleme, yedekleme, kayıt tutma, tedarikçi erişimi ve olay bildirimi için temel kurallar yazılmalıdır. Politika hedefi tanımlar; prosedür, hedefin hangi adımlarla yerine getirileceğini açıklar.
3. Rolleri ve vekilleri belirleyin. Bir olay lideri, teknik müdahale sorumluları, hizmet sahipleri, iletişim sorumlusu ve gerektiğinde hukuk ile kişisel veri sorumluları tanımlanır. Kişi izinli veya ulaşılamaz olduğunda devreye girecek vekil de kayıtlı olmalıdır.
4. Karar yetkilerini önceden verin. Hesap kapatma, sunucu izolasyonu, dış erişimi durdurma, acil değişiklik ve hizmete geri dönüş için hangi seviyede onay gerektiği belirlenir. Devam eden zararda hızlı hareket etmeyi sağlayan önceden onaylı işlemler oluşturulur; sonradan karar gerekçeleri kayıt altına alınır.
5. Risk kabulü ve istisna sürecini kurun. Uygulanamayan bir kontrol için gerekçe, iş etkisi, alternatif önlem, sorumlu, son tarih ve yeniden değerlendirme zamanı bulunmalıdır. Süresiz ve sahipsiz istisnalar, görünmeyen güvenlik borcu oluşturur.
6. Tedarikçi koşullarını değerlendirin. Hizmet sağlayıcının güvenlik sorumlulukları, olay bildirimi, log sağlama, veri erişimi, erişim iptali, yedekleme ve hizmet sonlandırma koşulları sözleşme ve teknik plan içinde karşılık bulmalıdır.
7. Güvenlik performansını düzenli gözden geçirin. Açık kritik riskler, geciken aksiyonlar, geri yükleme testleri, olay eğilimleri ve kaynak eksikleri yönetim tarafından değerlendirilir. Sadece araç sayısını raporlamak yerine, hizmetlerin hangi kanıtlarla korunduğu açıklanır.
Sorumlular ve gerekli kayıtlar
Üst yönetim, risk toleransı ve kaynak kararlarından sorumludur. Güvenlik sorumlusu süreçleri koordine eder; BT ekibi teknik kontrolleri işletir; hizmet sahipleri iş etkisini ve kabul koşullarını belirler. Küçük bir ekipte aynı kişi birden fazla rol alabilir, ancak kritik değişikliği yapan kişinin sonucu başka bir kişiyle doğrulaması mümkün olduğu ölçüde sağlanmalıdır.
Gerekli kayıtlar; onaylı politika ve prosedürler, görev matrisi, iletişim listesi, risk kabul belgeleri, tedarikçi değerlendirmeleri, toplantı kararları ve aksiyon takibidir. Her belgenin sahibi, sürümü ve gözden geçirme tarihi bulunur. Bir prosedürün gerçekte uygulanıp uygulanmadığı tatbikat ve örnek olay incelemesiyle sınanır.
Başarı ölçütleri ve uygulama örneği
Yönetişimin işe yaradığını; kritik hizmetlerin sahibi olması, olay sırasında yetki tartışması yaşanmaması, istisnaların süresinde değerlendirilmesi ve geciken risk aksiyonlarının yönetim gündemine gelmesi gösterir. Bir sunucuda fidye yazılımı belirtisi görüldüğünde olay lideri önceden tanımlı izolasyon yetkisini kullanır; hizmet sahibi kesinti etkisini yönetir; iletişim sorumlusu doğrulanmış bilgilerle açıklama yapar. Böylece teknik müdahale ile kurumsal karar aynı kayıt üzerinden ilerler.
Sık hata, politikanın yalnızca denetimde gösterilmek için yazılmasıdır. Diğer hatalar; bütün sorumluluğun BT ekibine bırakılması, yönetimin hiçbir riski yazılı kabul etmemesi ve tedarikçi erişimlerinin sahiplenilmemesidir. Yönetişim her adımda devam eder; bir kez tamamlanıp bırakılan başlangıç işi değildir.
01 Varlıkları ve verileri belirle
Amaç ve kapsam
Bu adım, korunacak ortamın gerçek durumunu ortaya çıkarır. Hangi cihazın, hesabın, uygulamanın veya veri kümesinin var olduğu bilinmiyorsa ona uygun koruma, izleme ve kurtarma planı da kurulamaz. Envanter yalnızca bilgisayar isimlerinden oluşmaz; iş hizmetleri, bağımlılıklar, veri akışları, sahipler ve dış erişimlerle birlikte tutulur.
Kapsama fiziksel ve sanal sunucular, kullanıcı bilgisayarları, mobil cihazlar, ağ cihazları, depolama, yedekleme sistemleri, yazıcılar, IoT ve gerektiğinde OT cihazları alınır. Yazılım tarafında işletim sistemleri, uygulamalar, veritabanları, eklentiler, paketler, API uçları, bulut kaynakları, alan adları ve sertifikalar yer alır. İnsan hesaplarının yanında servis hesapları, API anahtarları ve otomasyon kimlikleri de tanımlanır.
Envanterin oluşturulması
1. Her varlığa benzersiz bir kimlik verin. Varlık adı, türü, IP veya alan adı, bulunduğu ortam, işletim sistemi ve yazılım sürümü, sahibi, destek durumu ve son doğrulama tarihi kaydedilir. Varlık ile onu sağlayan hizmet arasındaki ilişki ayrıca tutulur.
2. İş hizmetlerini eşleyin. Örneğin müşteri portalının çalışması; DNS, sertifika, kimlik hizmeti, uygulama sunucusu, veritabanı ve ağ erişimine bağlı olabilir. Sadece uygulama sunucusunu kritik saymak, diğer bağımlılıkların kesintide unutulmasına neden olur.
3. Verinin nerede bulunduğunu ve nereye aktığını belirleyin. Toplama, işleme, depolama, paylaşma, yedekleme ve silme aşamaları incelenir. Üretim ortamından test ortamına kopyalanan bilgiler, çalışan bilgisayarlarındaki dışa aktarımlar ve tedarikçiye gönderilen dosyalar da kapsamda olmalıdır.
4. Veri sınıflarını tanımlayın. Örnek sınıflar; herkese açık, kurum içi, gizli ve erişimi özel olarak kısıtlı bilgilerdir. Her sınıf için erişim, aktarım, şifreleme, paylaşım ve saklama kuralları belirlenir. Sınıfların isimleri kurum tarafından değiştirilebilir.
5. Dışa açık yüzeyi kontrol edin. İnternete açık yönetim panelleri, unutulan test uygulamaları, eski alan adları, erişilebilir depolar ve kullanılmayan hesaplar aranır. Kurumun bildiği envanter ile dışarıdan gözlenebilen yüzey karşılaştırılır.
6. Envanteri birden fazla kaynakla doğrulayın. Dizin hizmeti, cihaz yönetimi, ağ kayıtları, sanallaştırma platformu, bulut yönetimi, satın alma ve yazılım kayıtları birlikte kullanılır. Sadece bir ağ taramasına dayanmak, kapalı veya farklı ağdaki varlıkları kaçırabilir.
7. Yaşam döngüsünü işletin. Yeni varlık açılırken envantere eklenir; değişiklikte güncellenir; kullanım dışına çıktığında erişimleri ve verileri uygun biçimde kaldırılır. Envanter ile değişiklik yönetimi birbirine bağlanmalıdır.
Kritik ayrıntılar
Sahiplik iki ayrı anlam taşır. Teknik sahibi sistemi yönetir; iş sahibi sistemin hangi amaçla kullanıldığını ve kesintinin etkisini açıklar. Bir veri kümesinin sahibi de kimlerin erişebileceğini ve ne kadar tutulacağını belirler. Sahibi bulunmayan varlıklar öncelikli olarak incelenmelidir; bunlar sıklıkla güncelleme ve izleme dışında kalır.
Tarama yöntemi ortamın hassasiyetine göre seçilir. Bir ofis bilgisayarında uygun olan aktif tarama, endüstriyel kontrol cihazında sorun oluşturabilir. OT ortamında işletme ve üreticiyle değerlendirilmiş, kontrollü yöntemler veya pasif keşif tercih edilmesi gerekebilir. Hassas veriler keşif sırasında gereksiz yere kopyalanmaz; kayıtlar da erişim kontrolüyle korunur.
Sorumlular ve çıktılar
BT ekibi cihaz ve platform envanterini, uygulama ekibi yazılım bağımlılıklarını, veri sahipleri sınıflandırmayı, satın alma ve tedarikçi sorumluları dış hizmetleri doğrular. Çıktılar; güncel varlık listesi, kritik hizmet listesi, bağımlılık haritası, veri akışları, hesap envanteri ve dışa açıklık kayıtlarıdır.
Başarı ölçütleri; kritik varlıkların sahibi ve sınıfının belirlenmesi, bilinmeyen varlıkların azaltılması, destek dışı yazılımların görünür olması ve değişikliklerin envantere zamanında yansımasıdır. Varlığın kayıtlı olması korunmuş olduğu anlamına gelmez; kaydı risk değerlendirmesine temel sağlar.
Uygulama örneği ve sık hatalar
Bir web hizmetinde uygulama sunucusu kayıtlıyken veritabanı yedeğinin kişisel bir bulut hesabına aktarıldığı fark edilebilir. Bu bulgu; veri akışının, erişim sahibinin ve yedek güvenliğinin yeniden değerlendirilmesini gerektirir. Envanter böylece yalnızca sayım değil, güvenlik sorunu ortaya çıkaran bir çalışma olur.
Sık hatalar; yalnızca fiziksel cihazları listelemek, servis hesaplarını unutmak, test ortamını önemsiz görmek ve kritikliği cihaz fiyatına göre belirlemektir. Ucuz bir ağ cihazı bütün hizmetlerin tek geçiş noktası olabilir. Sonraki adımda bu varlıkların tehditleri, zafiyetleri ve iş etkileri değerlendirilir.
02 Riskleri değerlendir ve önceliklendir
Amaç ve temel kavramlar
Risk değerlendirmesi, kaynakların hangi soruna önce ayrılacağını belirler. Tehdit, zarar verebilecek aktör veya durumdur. Zafiyet, bu zararın gerçekleşmesini kolaylaştıran eksikliktir. Etki, olay gerçekleştiğinde ortaya çıkan iş sonucudur. Risk; belirli bir senaryonun gerçekleşme olasılığı, etkisi, mevcut kontroller ve belirsizliklerle birlikte değerlendirilir. Zafiyetin teknik önem puanı, tek başına kurumun riskini anlatmaz. [K3]
Örneğin internete açık bir yönetim panelindeki zayıf kimlik doğrulama, saldırganın yönetici erişimi kazanmasına ve kritik veriyi değiştirmesine yol açabilir. Aynı zafiyet izole bir laboratuvar sisteminde farklı iş etkisine sahip olabilir. Buna karşılık düşük teknik puanlı bir açıklık, kritik bir iş akışında veya başka açıklıklarla birlikte ciddi sonuç doğurabilir.
Değerlendirme adımları
1. Kapsamı ve yöntemi belirleyin. Hangi hizmetler incelenecek, kimler bilgi verecek ve hangi ölçek kullanılacak? Olasılık ve etkinin ne anlama geldiği önceden tanımlanır; farklı ekiplerin aynı bulguyu tutarlı değerlendirmesi sağlanır.
2. Risk senaryoları yazın. Senaryo; varlık, tehdit, zafiyet ve beklenen sonucu açıkça birleştirmelidir. Sadece “sunucu güvensiz” yazmak yerine “internete açık yönetim hesabının ele geçirilmesiyle müşteri verilerinin izinsiz dışarı aktarılması” gibi somut bir açıklama kullanılır.
3. Mevcut kontrolleri kanıtlarla inceleyin. MFA açık mı, yama gerçekten uygulanmış mı, yedek geri yüklenebiliyor mu, alarm görülüyor mu? Kurulu bir ürünün veya yazılı politikanın varlığına bakarak riski düşürmeyin; etkinliği test sonuçlarıyla değerlendirin.
4. Olasılığı değerlendirin. Dışa açıklık, saldırganın ihtiyaç duyduğu erişim, aktif istismar bilgisi, zafiyetin kullanılabilirliği, kullanıcı davranışı ve geçmiş olaylar dikkate alınır. Bilgi eksikse varsayımlar ve değerlendirmeye duyulan güven açıkça yazılır.
5. İş etkisini değerlendirin. Hizmet kesintisi, veri kaybı, yetkisiz değişiklik, mali kayıp, sözleşme etkisi, kişisel veri etkisi ve gerekiyorsa fiziksel güvenlik sonuçları incelenir. Teknik ekip, iş sahibinin katkısı olmadan bu etkiyi tek başına belirlememelidir.
6. Risk işleme seçeneğini belirleyin. Risk azaltılabilir, riskli faaliyet durdurularak kaçınılabilir, sözleşme veya sigorta üzerinden bir kısmı paylaşılabilir ya da yetkili iş sahibi tarafından kabul edilebilir. Paylaşma, bütün teknik ve kurumsal sorumluluğu ortadan kaldırmaz.
7. Aksiyonları takip edin. Her riskte sorumlu, uygulanacak kontrol, hedef tarih, öncelik, bağımlılık, kalan risk ve kabul kararı bulunur. İşlem tamamlandığında yeniden değerlendirme yapılır; yalnızca görev kapatmak yeterli değildir.
Önceliklendirmede dikkat edilecek noktalar
Basit bir 1 ile 5 ölçeğinde olasılık ve etki puanları kullanılabilir. Bu yaklaşım karşılaştırma için pratik olabilir, fakat matematiksel kesinlik sağlamaz. Aynı toplam puanı alan iki senaryo, biri veri kaybı diğeri kısa kesinti içerdiği için farklı ele alınabilir. Bu nedenle sayısal puanın yanında açıklama ve iş bağlamı mutlaka korunur.
Aktif olarak kullanılan bir açıklık, internete açık kritik hizmet, yönetici yetkisi, kimlik altyapısı veya yedekleme sisteminin etkilenmesi önceliği yükseltebilir. Yama hemen uygulanamıyorsa dış erişimi sınırlama, ek izleme ve ayrıcalığı azaltma gibi geçici önlemler değerlendirilir. Geçici önlemin sahibi ve sona erme koşulu bulunmalıdır.
Sorumlular ve gerekli kayıtlar
Güvenlik ekibi senaryoları ve tehditleri, BT ile uygulama ekipleri zafiyetleri ve düzeltme seçeneklerini, hizmet sahipleri iş etkisini değerlendirir. Risk kabulünü, bu sonucu sahiplenebilecek yetkili yönetici verir. Çıktılar; risk kayıt listesi, yöntem açıklaması, kontrol kanıtları, risk işleme planı, istisnalar ve kalan risk onaylarıdır.
Başarı; kritik risklerin görünür olması, aksiyonların doğru sırada yürütülmesi, süresi geçen risklerin üst seviyeye taşınması ve tamamlanan düzeltmelerin yeniden doğrulanmasıyla ölçülür. Yalnızca taramada çıkan açıklık sayısını azaltmak, iş riskinin azaldığını her zaman göstermez.
Uygulama örneği ve sık hatalar
Destek dışı bir işletim sisteminde çalışan kritik uygulamanın hemen taşınması mümkün olmayabilir. Risk kaydı, dış erişimin kapatılmasını, yönetim erişiminin ayrı bir geçiş üzerinden verilmesini, sıkı izlemeyi ve tarihli bir taşıma planını birlikte içerebilir. Yönetim kalan riski bu şartlarla kabul eder; koşullar değişirse karar yeniden değerlendirilir.
Sık hatalar; bütün riskleri kritik saymak, yalnızca teknik puana göre hareket etmek, risk sahibini belirlememek ve uygulanmayan kontrolleri uygulanmış varsaymaktır. Risk değerlendirmesi; yeni varlık, büyük değişiklik, önemli tehdit bilgisi veya olay sonrası tekrar ele alınır.
03 Koruyucu kontrolleri uygula
Amaç ve kontrol yaklaşımı
Koruyucu kontroller, öncelikli risklerin gerçekleşme olasılığını ve gerçekleştiğinde etkisini azaltır. Kontroller teknik, idari ve fiziksel alanlarda birlikte çalışır. Kimlik yönetimi, ağ sınırlandırması, güvenli yapılandırma, veri koruması ve insan davranışı aynı savunma düzeninin parçalarıdır. Bir kontrolün başarısı, kurulumunun yapılmasıyla değil hedeflenen riske karşı etkili olduğunun görülmesiyle anlaşılır.
Kontrol seçimi risk işleme planına dayanır. Kritik hizmeti kesintiye uğratabilecek bir değişiklik önce uygun ortamda test edilir. Kontrolün uygulanamadığı durumlar gerekçeli, süreli ve onaylı istisna olarak tutulur. NIST SP 800-53; erişim, denetim, yapılandırma, bakım, süreklilik ve diğer güvenlik alanları için bir kontrol kataloğu sağlar. Kurum, kataloğu kendi risklerine göre kullanır. [K4]
Kimlik ve erişim yönetimi
Kullanıcı, yönetici ve servis hesapları ayrılır. Her kişinin ihtiyacı kadar erişim verilmesi, en az yetki ilkesidir. İşe girişte yetki onaylanır, görev değişikliğinde gözden geçirilir, işten ayrılmada kaldırılır. Ortak yönetici hesapları yerine kişiye bağlı hesaplar ve izlenebilir ayrıcalıklı erişim düzeni tercih edilir. Acil durum hesabı gerekiyorsa kullanım şartları, korunması ve her kullanımın incelemesi belirlenir.
MFA özellikle yönetici, uzaktan erişim ve kritik uygulama hesaplarında kullanılır. Yüksek riskli erişimlerde kimlik avına dayanıklı yöntemler değerlendirilir. MFA bütün saldırıları önlemez; çalınmış oturum, kötü yapılandırılmış kurtarma süreci veya aşırı yetki de risk yaratabilir. Hesap kurtarma, cihaz kaybı ve yedek doğrulama yolları ana giriş yöntemi kadar dikkatle tasarlanır.
Servis hesapları ve API anahtarları belirli bir amaca bağlanır. Gereksiz etkileşimli giriş kapatılır, izinler daraltılır, kullanım izlenir ve sırlar uygun bir gizli bilgi yönetimi düzeninde saklanır. Uygulama kodunda, kaynak depoda, destek kaydında veya loglarda parola ve anahtar bırakılmaz. Sır yenileme işlemi, bağlı hizmetleri bozmaması için planlanır.
Cihazlar ve yazılımlar
Desteklenen işletim sistemi ve yazılımlar kullanılır. Güvenlik yamaları, cihaz yazılımları, uygulama bağımlılıkları ve eklentiler takip edilir. Kritik düzeltme test edilip uygulanır; sonrasında sürüm ve tekrar tarama ile doğrulanır. Yama uygulanması, önceden gerçekleşmiş bir ihlalin temizlendiği anlamına gelmez.
Güvenli yapılandırmada gereksiz servisler, varsayılan hesaplar ve kullanılmayan protokoller kapatılır. Uç nokta koruması, cihazın türüne uygun EDR veya benzer kontrollerle desteklenir. Disk şifreleme, ekran kilidi, uygulama çalıştırma sınırları ve taşınabilir medya kuralları veri riskine göre seçilir. Cihazlara ait güvenlik ayarlarının zamanla değişmesi de izlenmelidir.
Uygulama güvenliği; sunucu tarafı yetki kontrolü, girdi doğrulama, güvenli oturum, hata yönetimi, sır yönetimi ve bağımlılık kontrolünü kapsar. Geliştirme, test ve üretim ayrılır; değişiklikler gözden geçirilir. Üretim verisinin testte kullanılmasına ihtiyaç varsa veri minimizasyonu veya uygun maskeleme yapılır. Yedek ve yönetim uçlarının uygulamanın ana ekranı kadar korunması gerekir.
Ağ ve iletişim güvenliği
Kullanıcı, sunucu, yönetim, misafir ve gerektiğinde üretim ağları uygun biçimde ayrılır. Bölümlendirme, sadece farklı VLAN oluşturmakla tamamlanmaz; bölgeler arası akışların kurallarla sınırlandırılması ve test edilmesi gerekir. Yönetim panelleri doğrudan internete açılmak yerine kontrollü erişim yollarıyla korunur. Gelen ve gereken durumlarda giden trafik, hizmet ihtiyacına göre sınırlandırılır.
Firewall, WAF ve IDS/IPS farklı amaçlara hizmet eder. Firewall erişim akışlarını, WAF web uygulamasına yönelik bazı saldırıları, IDS/IPS incelenebilen ağ trafiğindeki belirtileri ele alır. Şifreli trafik ve kapasite sınırları görünürlüğü etkileyebilir. Büyük hacimli DDoS saldırısı internet hattını dolduruyorsa, yerel firewall tek başına yeterli olmayabilir; sağlayıcı veya üst ağ tarafındaki koruma ayrıca değerlendirilir.
Zero Trust yaklaşımında yalnızca kurum ağında bulunmak güven için yeterli sayılmaz. Kullanıcı, cihaz, yetki ve istenen kaynak birlikte değerlendirilir. Ağ bölümlendirmesi bu yaklaşımı destekleyebilir, fakat tek başına Zero Trust mimarisi oluşturmaz. [K5]
Veri koruması ve yedekleme
Hassas veri aktarımda ve uygun depolarda şifrelenir; anahtarlara erişim veriden ayrı yönetilir. Paylaşım izinleri daraltılır, dış bağlantılar ve toplu dışa aktarımlar kontrol edilir. Saklama süresi dolan verinin silinmesi planlanır. Veri koruması sadece dış saldırıyı değil, yanlış paylaşım ve gereksiz kopyalama gibi hataları da kapsar.
Yedekler, üretim ortamındaki bir saldırının hepsini silemeyeceği veya değiştiremeyeceği biçimde korunur. Ayrı kimlikler, erişim sınırları, çevrimdışı ya da değiştirilemez kopyalar ve farklı konumlar risklere göre değerlendirilir. Veritabanı gibi sistemlerde tutarlı geri yükleme sağlanmalıdır. Replikasyon ve sanal makine anlık görüntüsü, tek başına bağımsız ve güvenli yedek sayılmaz; aynı hatayı veya şifrelemeyi taşıyabilir.
E posta ve iletişim hizmetleri
E-posta; kimlik avı, sahte ödeme talebi ve hesap ele geçirilmesi açısından önemli bir giriş noktasıdır. Alan adı doğrulama ve sahteciliği azaltma için SPF, DKIM ve DMARC gibi mekanizmalar hizmetin yapısına göre planlanır. Yanlış yapılandırma meşru postayı etkileyebileceği için izleme ve kademeli uygulama gerekir. Bu mekanizmalar benzer görünümlü başka alan adlarını, bütün zararlı içerikleri veya ele geçirilmiş meşru hesabı tek başına engellemez.
Ek ve bağlantı incelemesi, dış yönlendirme kurallarının takibi, posta kutusu yetkileri ve olağan dışı giriş kontrolü birlikte değerlendirilir. Finansal veya hassas işlem taleplerinde bağımsız doğrulama süreci oluşturulur. E-postada gelen telefon numarasını aramak yerine kurumun bilinen iletişim kaydı kullanılır. Posta hesabı ihlalinde yalnızca parola değil; yönlendirme, temsilci erişimi, uygulama izinleri ve oturumlar da araştırılır.
İnsan ve fiziksel güvenlik
Çalışanlar şüpheli e-posta, beklenmeyen MFA isteği, sahte destek talebi ve veri paylaşımı konusunda rolüne uygun eğitim alır. Bildirimi kolaylaştıran bir kanal sağlanır; hatasını erken bildiren kişiyi cezalandıran kültürden kaçınılır. Fiziksel erişim, ziyaretçi kontrolü, cihaz teslimi, güvenli imha ve enerji ile çevre koşulları da hizmetlerin korunmasına katkı verir.
Doğrulama ve geçiş koşulları
Kontrol sahibinin, uygulama tarihinin, yapılandırmanın ve test kanıtının kaydı tutulur. Yetki testi, yama doğrulaması, yedekten geri dönüş, ağ erişim testi ve kontrollü alarm üretimiyle kontroller sınanır. Başarı ölçütleri; kritik hesaplarda uygun MFA kapsamı, geciken yamalar, gereksiz ayrıcalıklar, test edilmiş yedek kapsamı ve güvenli yapılandırma uyumudur.
Sık hata, ürün satın almayı riski çözmekle eş tutmaktır. Kontroller izlenmezse bozulabilir; istisnalar sınırsız genişleyebilir. Bu yüzden koruma sürekli izlemeye bağlanır ve kritik değişikliklerden sonra tekrar doğrulanır.
04 Sürekli izle ve tespit et
Amaç ve kapsam
İzleme, güvenlik kontrollerinin durumunu ve şüpheli davranışları görünür kılar. Koruma her saldırıyı engelleyemediği için tespit kapasitesi gerekir. İzleme; ağ trafiği kadar kimlik sistemleri, cihazlar, uygulamalar, bulut, veritabanı, yedekleme ve güvenlik araçlarının kendi durumunu da kapsar. Alarm üretmeyen bir sistemin gerçekten güvenli mi yoksa görünmez mi olduğu ayırt edilmelidir.
Bir güvenlik olayı kaydı ile alarm farklıdır. Başarılı giriş, dosya erişimi veya kural değişikliği sistem olayıdır. Bir tespit kuralı bu kayıtlar içinde şüpheli bir örüntü bulduğunda alarm üretebilir. Alarm ise inceleme gerektiren bir işarettir; her alarm doğrulanmış ihlal değildir.
Log toplama ve veri kalitesi
1. Kritik kaynakları belirleyin. Dizin ve kimlik sağlayıcısı, VPN, firewall, DNS, uç nokta, uygulama, web sunucusu, bulut yönetimi ve yedekleme kayıtları öncelikli adaylardır. Kaynak seçimi, hangi saldırı veya iş riski senaryosunu tespit etmek istediğinize göre yapılır.
2. Anlamlı alanları toplayın. Zaman, kaynak ve hedef, kullanıcı veya servis kimliği, işlem, sonuç, cihaz kimliği, oturum veya ilişkilendirme kimliği ve gerekli teknik ayrıntılar korunur. Parola, token veya gereksiz kişisel veri loga yazılmaz.
3. Zamanları tutarlı hale getirin. Saat eşitleme ve saat dilimi bilgisi, farklı kaynakların olaylarını birleştirmeyi sağlar. Ham zaman damgaları korunur; yorumlanan zamanın hangi dilimde olduğu açıklanır. Yanlış saatler, saldırının sırasını yanlış göstermeye neden olabilir.
4. Merkezi toplama ve koruma kurun. SIEM veya uygun bir merkezi kayıt sistemiyle loglar aranabilir ve ilişkilendirilebilir hale getirilir. Erişimler sınırlandırılır, aktarım ve saklama korunur. Saldırganın ele geçirdiği cihazdaki yerel kayıtları silmesi, bütün geçmişi yok etmemelidir.
5. Kayıt akışının sağlığını izleyin. Kaynak sessizliği, ajan durması, işleme hatası, disk doluluğu, saat kayması ve depolama başarısızlığı da alarm üretmelidir. Beklenmedik biçimde kesilen log akışı güvenlik kör noktasıdır.
6. Saklama ve erişim düzenini belirleyin. Saklama süresi; inceleme ihtiyacı, hizmet riski, maliyet, kişisel veri ilkeleri ve geçerli yükümlülüklerle belirlenir. Her kayıt için aynı süreyi varsaymak yerine kaynak ve kullanım gerekçesi açıklanır.
Tespit kurallarının oluşturulması
Başlangıç senaryoları; çok sayıda başarısız girişin ardından başarı, olağan dışı yönetici yetkisi, yeni ayrıcalıklı hesap, güvenlik aracının kapatılması, kritik dosya değişikliği, yedeklerin silinmesi, beklenmeyen dış veri aktarımı ve şüpheli süreç zinciri olabilir. Her kuralın amacı, veri kaynakları, eşiği, sorumlusu ve inceleme adımları yazılır.
Normal davranış bilgisi önemlidir. Gece çalışan bir yedekleme işi, aynı saatte toplu veri aktarımı yapabilir. Buna karşılık aynı işin farklı hedefe, farklı hesapla veya izin dışı veriyle çalışması şüphelidir. Kurallar bakım penceresi, onaylı otomasyon ve hizmet takvimiyle birlikte değerlendirilir; geniş istisnalarla bütün davranış görünmez hale getirilmez.
SIEM merkezi ilişkilendirme sağlar; EDR uç nokta süreçleri ve bazı müdahale işlemlerini görünür kılar; IDS/IPS ağdaki tespit edilebilir davranışları ele alır. Araçlar birbirini tamamlar. Şifreli trafik, yanlış sensör konumu, eksik yetki veya kapalı ajan görünürlüğü azaltabilir. Araç seçiminden önce veri kapsamı ve işletme sorumluluğu netleştirilir.
Alarm işletimi ve sorumlular
Alarmlar önem düzeyine göre sıraya alınır. Hangi seviyenin ne kadar sürede inceleneceği kurum tarafından onaylanır; mesai dışı durum ve ulaşılamayan sorumlu için yükseltme yolu bulunur. Bir alarmın e-posta göndermesi yeterli değildir; bir kişinin görmesi, değerlendirmesi ve kayda bağlaması gerekir.
Güvenlik ekibi veya izleme hizmeti kural ve incelemeyi, BT ekibi ajan ile kaynak sağlığını, uygulama sahipleri iş bağlamını yönetir. Çıktılar; log kaynak listesi, tespit senaryoları, alarm kayıtları, veri kalite sorunları ve test sonuçlarıdır.
Başarı ölçütleri ve sık hatalar
Kritik varlıkların log kapsamı, veri akışı kesintileri, inceleme gecikmesi, doğru sonuçlandırılan alarmlar ve kontrollü testlerin yakalanması izlenir. Az alarm gelmesi kendi başına başarı değildir. Çok alarm üretip hepsini görmezden gelmek de güvenlik sağlamaz; doğruluk ve işlem kapasitesi birlikte değerlendirilir.
Şüpheli olay yoksa izleme sürer. Düzenli gözden geçirmede yeni riskler ve eksik kontroller belirlenerek 01, 02 ve 03 adımlarına geri besleme yapılır. Şüpheli durum varsa 05 ve 06 adımları devreye girer. En sık hatalar; log toplama ile tespiti aynı sanmak, test etmeden kural açmak ve izleme sisteminin kendi sağlığını takip etmemektir.
05 Olay müdahalesine geç
Amaç ve bu adımın diğerlerinden farkı
Bu adım, şüpheli durumun normal izleme kuyruğunda kaybolmamasını ve düzenli bir olay değerlendirmesine aktarılmasını sağlar. Aktarım, saldırının kesinleştiği anlamına gelmez. 05 numaralı adım; kayıt, sorumlu, iletişim ve müdahale hazırlığını başlatır. 06 numaralı adım ise teknik bulgularla doğrulama ve öncelik değerlendirmesini ayrıntılandırır.
Müdahale kanalı yalnızca otomatik alarm değildir. Kullanıcının şüpheli bağlantı bildirmesi, tedarikçinin olay duyurması, verinin beklenmedik biçimde değişmesi, harici bir güvenlik araştırmacısının bildirimi veya müşteri şikayeti de giriş oluşturabilir. Bildirim kaynağı güvenilirlik açısından incelenir, fakat insan tarafından gelen bildirim araç alarmından değersiz sayılmaz.
Müdahalenin başlatılması
1. Tekil bir olay değerlendirme kaydı açın. Bildirim zamanı, tespit kaynağı, ilk belirtiler, ilgili varlık ve ilk sorumlu kaydedilir. Aynı duruma ait alarmlar, ilişkili kayıtlarla tek olay çevresinde toplanır; bağımsız bulgular yanlışlıkla birleştirilmez.
2. Bildirimi alan kişi ilk yönlendirmeyi yapar. Kullanıcıdan gerekli bilgiler istenir, şüpheli dosya veya bağlantıyla tekrar etkileşime girmemesi söylenir. Kullanıcıya kendi başına log silme, temizleme veya biçimlendirme yaptırılmaz.
3. Olay sorumlusu atanır. İlk değerlendirmeyi kimin yapacağı ve gerektiğinde olay liderinin kim olacağı belirlenir. Ekip farklı araçlardan çalışsa bile durum, karar ve aksiyonlar ortak kayıtta görünür olmalıdır.
4. İlk iş etkisini değerlendirin. Kritik hizmet kesintisi, yönetici hesap kullanımı, veri dışa aktarımı veya devam eden dosya şifreleme gibi işaretler hızlı yükseltme gerektirebilir. Etkin zarar sürerken kesin kök neden için beklemek doğru olmayabilir.
5. Güvenli iletişim kurun. Kurum e-postasının veya mesajlaşmanın etkilenmiş olabileceği durumda, önceden hazırlanmış alternatif iletişim kanalı kullanılır. Herkesin rastgele dış grup oluşturması yerine onaylı, erişimi sınırlı iletişim tercih edilir.
6. İlgili müdahale planını seçin. Hesap ele geçirilmesi, zararlı yazılım, fidye yazılımı, web saldırısı, veri sızıntısı ve DDoS farklı teknik adımlar içerebilir. Planlar mevcut araçlara, hizmetlere ve yetkilere göre hazır tutulur.
7. Delil ve log kaybını önleyin. Kısa süre saklanan loglar ve geçici bilgiler belirlenir; uygun koruma işlemleri başlatılır. Her işlem kim tarafından, ne zaman ve neden yapıldığıyla kaydedilir.
Koordinasyon ve karar düzeni
Olay lideri işlerin sırasını ve güncel durumu koordine eder. Teknik liderler ağ, cihaz, kimlik veya uygulama çalışmalarını yürütür. Hizmet sahibi iş kesintisini yönetir. Gerektiğinde tedarikçi, yönetim, hukuk ve veri sorumluları sürece katılır. İletişim sorumlusu doğrulanmış bilgileri paylaşır; teknik tahminler kesin sonuç gibi duyurulmaz.
Durum güncellemesinde şu bilgiler ayrılır: doğrulanmış gerçekler, araştırılan hipotezler, henüz bilinmeyenler, alınan önlemler, etkilenmiş hizmetler ve bir sonraki değerlendirme zamanı. Bir sonraki güncelleme zamanı belirlemek, ekip ve yönetimin sürekli farklı kişilerden bilgi istemesini azaltır.
Kayıtlar ve geçiş koşulları
Başlangıç kaydı; olay kimliği, tespit ve bildirim zamanları, olay kategorisi, ilk önem düzeyi, etkilenen varlıklar, sorumlular, iletişim kanalı ve ilk aksiyonları içerir. Kayıt durumu “incelemede” olabilir; doğrulama sonrası değişir. İletişim ve acil değişiklik onayları da kayıtla ilişkilendirilir.
Başarı ölçütleri; bildirimin kayda dönüşmesi, uygun kişiye ulaşması, gerekli logların korunması ve ilk iş etkisinin anlaşılmasıdır. Sonraki adım 06 numaralı doğrulamadır. Devam eden ciddi zararda, önceden yetkilendirilmiş sınırlama işlemleri doğrulama ile eş zamanlı yürüyebilir.
Uygulama örneği ve sık hatalar
Bir çalışan beklemediği MFA isteğini onayladığını bildirir. İlk kayıt açılır, hesabın ve cihazın kimliği alınır, kimlik loglarının saklanması sağlanır ve ilgili sorumluya aktarılır. Yetkisiz başarılı giriş bulunup bulunmadığı 06 numaralı adımda araştırılır; belirgin kötüye kullanım görülürse erişim sınırlaması geciktirilmez.
Sık hatalar; her alarmı kesin ihlal ilan etmek, bildirimleri yalnızca telefon konuşmasında bırakmak, farklı ekiplerin çelişen işlemler yapması ve iletişim için etkilenmiş sistemi kullanmaktır. Düzenli aktarım, müdahalenin sonraki adımlarında zaman ve bilgi kaybını azaltır.
06 Alarmı doğrula ve önceliklendir
Amaç ve sonuç sınıfları
Doğrulama, alarmın gerçek bir güvenlik olayını gösterip göstermediğini anlamaya çalışır. Tek bir göstergenin kötü amaçlı olması, her zaman bütün sistemin ele geçirildiğini kanıtlamaz. Aynı şekilde bir aracın tehdit bulmaması da ihlali dışlamaz. Sonuç; ham kayıtlar, bağımsız kaynaklar, iş bağlamı ve veri kapsamıyla birlikte değerlendirilir.
Değerlendirme sonucu en az üç şekilde ayrılmalıdır. Doğrulanmış olay; yetkisiz veya zararlı faaliyetin yeterli kanıtla desteklendiği durumdur. Yanlış alarm ya da güvenlik ihlali oluşturmayan meşru faaliyet; bulgunun açıklanabildiği durumdur. Sonuçlandırılamamış şüphe ise verinin yetersiz olduğu ve incelemenin sürmesi gereken durumdur. Şemadaki “Hayır” kolu, yalnızca gerekçeli sonuçlandırmada yanlış alarm olarak kullanılır; bilinmeyen sonuç otomatik kapatılmaz.
Doğrulama adımları
1. Alarmın ham verisini inceleyin. Kural adı, ilgili kayıt, zamanı, kullanıcı, süreç, IP, hedef ve işlem sonucu kontrol edilir. Görselleştirilmiş alarm özeti eksik bilgi içerebilir; mümkünse asıl logla doğrulanır.
2. Kaynak sağlığını değerlendirin. Ajan çalışıyor mu, saat doğru mu, kayıt alanları tam mı, işleme hatası var mı? Yanlış veri veya kesilmiş kayıt akışı, hem sahte alarm hem yanlış güven duygusu oluşturabilir.
3. İş bağlamını kontrol edin. Bakım kaydı, onaylı test, görevli yönetici veya planlı otomasyon var mı? Meşru açıklama ilgili kişi ve kayıtla doğrulanır; yalnızca “muhtemelen bakım” denilerek kapatılmaz.
4. Bağımsız kaynaklarla karşılaştırın. Şüpheli giriş; kimlik sağlayıcısı, VPN ve cihaz kayıtlarıyla birlikte incelenebilir. Şüpheli dosya; süreç zinciri, dosya değişikliği ve ağ bağlantısıyla ilişkilendirilebilir. Birden fazla tutarlı kaynak güveni artırır.
5. Kapsamı ilk aşamada tahmin edin. İlgili hesap ve cihazlarla sınırlı mı, başka hizmetler de etkilenmiş olabilir mi? İlk tespit zamanı ile saldırının başlamış olabileceği zaman ayrılır. Tarama dönemi gerekirse daha eski kayıtlara genişletilir.
6. Hassas bulguları koruyun. Şüpheli dosya üretim cihazında tekrar çalıştırılmaz. Kurum içi dosya, kişisel veri veya sır içerebilecek örnekler onay olmadan herkese açık analiz hizmetine yüklenmez. Güvenli ve yetkili inceleme ortamı kullanılır.
7. Sonucu ve güven düzeyini kaydedin. Hangi kanıt neyi destekliyor, hangi veri eksik, hangi ihtimal elendi? Eksik görünürlük sonucu etkiliyorsa açıkça belirtilir ve ek veri toplama görevi açılır.
Önceliklendirme
Olayın önemi; iş etkisi, varlık kritiklik düzeyi, veri etkisi, erişim ayrıcalığı, yayılım ve devam eden zarara göre belirlenir. Kritik kimlik altyapısı veya yedekleme sistemi etkilenmişse tek bir cihazda görülen bulgu bile yüksek öncelik alabilir. Araç tarafından verilen alarm puanı, nihai olay önceliği yerine geçmez.
Eklerdeki önem tablosu örnek bir sınıflandırmadır. Kurumun kendi yanıt süreleri ve yükseltme eşikleri onaylanmalıdır. İnceleme ilerledikçe seviye yeniden değerlendirilir. Daha düşük seviyeye indirme de gerekçeli bir karardır; sadece ekip yoğun olduğu için seviye düşürülmez.
Sorumlular ve gerekli kayıtlar
Güvenlik analisti teknik doğrulamayı, ilgili BT veya uygulama sorumlusu bağlamı, hizmet sahibi iş etkisini sağlar. Olay lideri öncelik ve kaynak kararını koordine eder. Kayıtta; kanıt bağlantıları, testler, sonuç sınıfı, güven düzeyi, veri eksikleri ve öncelik gerekçesi bulunur.
Yanlış alarm kapatılırken kuralın tamamen kapatılması yerine dar ve doğrulanmış ayar yapılır. İstisna sahibi, gerekçe ve gözden geçirme zamanı belirlenir. Doğrulanmış olay 07 numaralı sınırlamaya aktarılır; belirsiz olay açık tutulur ve gerekli araştırma sürer.
Uygulama örneği ve sık hatalar
Başarısız girişlerden sonra başarılı giriş alarmı görüldüğünde, kullanıcının farklı cihaz denemesi mi yoksa yetkisiz oturum mu olduğu araştırılır. Girişin ardından olağan dışı yönetici yetkisi veya veri indirme görülmesi olayı güçlendirir. Kullanıcının yalnızca “ben yapmadım” demesi önemli bilgidir, ancak teknik kayıtlarla desteklenmelidir.
Sık hatalar; IP konumunu tek kanıt saymak, VPN nedeniyle görülen coğrafi farkı kesin saldırı kabul etmek, veri eksikliğini yanlış alarm saymak ve meşru açıklamayı kanıtsız kabul etmektir. Doğru sonuçlandırma, sonraki müdahalenin hem hızını hem kapsamını belirler.
07 Yayılımı sınırlandır
Amaç ve temel denge
Sınırlama, saldırganın erişimini ve zararın büyümesini durdurmaya çalışır. Amaç, etkilenen ortamı kontrol altına almak ve diğer varlıkların güvenliğini korumaktır. Bu aşama tehdidin tamamen kaldırılmasıyla aynı değildir. İzole edilmiş bir cihaz hâlâ zararlı bileşen veya çalınmış kimlik bilgisi içerebilir.
Kararda devam eden zarar, hizmet kesintisi, delil kaybı ve müdahale kapasitesi birlikte değerlendirilir. Aktif şifreleme veya veri aktarımı sürerken geniş analiz için beklemek zarar verebilir. Buna karşılık gereksiz biçimde bütün ağı kapatmak, iş hizmetlerini ve delil toplama yollarını etkileyebilir. Müdahale hedefi ve yetki kayıtlı olmalıdır.
Teknik sınırlama seçenekleri
1. Etkilenen cihaz veya sunucuyu uygun biçimde izole edin. EDR izolasyonu, ağ portu veya erişim kuralları kullanılabilir. Seçilen yöntemin hangi trafiği kestiği ve yönetim iletişimini koruyup korumadığı doğrulanır. Sadece interneti kesmek, yerel yayılımı durdurmayabilir.
2. Hesap ve oturum erişimini sınırlayın. Gerekli hesaplar geçici kapatılır veya ayrıcalıkları alınır. Desteklenen sistemlerde aktif oturumlar ve tokenlar iptal edilir. Parola değiştirmek tek başına bütün oturumları veya uygulama anahtarlarını geçersiz kılmayabilir; hizmetin davranışı doğrulanmalıdır.
3. Zararlı iletişimi engelleyin. Doğrulanmış hedefler ve akışlar uygun katmanda sınırlandırılır. Ortak IP veya alan adı altyapısının geniş biçimde engellenmesi meşru hizmeti etkileyebilir. Göstergenin güvenilirliği, kuralın kapsamı ve geri alınabilirliği değerlendirilir.
4. Hassas ve kritik sistemleri koruyun. Kimlik altyapısı, yedekler, yönetim ağı ve ana veri depolarına erişim özellikle kontrol edilir. Saldırganın henüz etkilemediği sistemlere ulaşma ihtimali incelenir. Yedek silme ve erişim değişiklikleri yakından izlenir.
5. İlgili hesap, cihaz ve uygulamalarda taramayı genişletin. İlk görülen cihazın dışındaki sistemlerde benzer belirtiler aranır. Sınırlama yalnızca alarm üreten varlığa odaklanırsa, sessiz kalmış diğer varlıklar üzerinden saldırı devam edebilir.
6. Acil değişiklikleri kaydedin. Kural, hesap veya servis değişikliğinin zamanı, yapan kişi, gerekçesi, onayı ve etkilenen hizmetler yazılır. Geçici önlemin ne zaman ve hangi koşulla kaldırılacağı belirlenir.
7. Sınırlamanın etkisini test edin. Zararlı trafik durmuş mu, erişim kesilmiş mi, başka yol kullanılıyor mu? İşlemin başarılı görünmesi yerine gerçek akış ve kayıtlar kontrol edilir.
Delil ve sistem durumu
Cihazı yeniden başlatma veya kapatma; bellek, bağlantı ve geçici süreç bilgilerini kaybettirebilir. Mümkün olduğunda ağ izolasyonu ile uygun delil toplama birlikte değerlendirilir. Ancak güvenlik veya devam eden ağır zarar gerektiriyorsa, kayıtlı bir kararla kapatma yapılabilir. “Her durumda açık tut” ya da “her durumda kapat” gibi koşulsuz kurallar uygun değildir.
Adli incelemeye ihtiyaç varsa, toplama işlemi yetkin kişilerce ve bütünlük korunarak yapılır. Alınan kopyaların kaynağı, zamanı, kullanılan araç ve uygun bütünlük doğrulaması kaydedilir. Bütünlük değeri bir dosyanın sonradan değişmediğini gösterebilir; dosyanın temiz veya iddianın doğru olduğunu tek başına kanıtlamaz. [K6]
İş sürekliliği ve sorumlular
Hizmet sahibi, alternatif işleyiş veya kontrollü kesinti planını devreye alır. Teknik ekip ağ, kimlik ve uç nokta sınırlarını uygular. Olay lideri işlemleri birlikte planlar; tedarikçi ve iş tarafı etkilerden haberdar edilir. Acil erişimlerin korunması, ancak saldırganın aynı yolu kullanmayacağı şekilde düzenlenmelidir.
Çıktılar; izolasyon listesi, kural değişiklikleri, hesap işlemleri, oturum iptal kayıtları, korunan deliller, hizmet etkileri ve sınırlama doğrulamasıdır. Başarı; yayılımın ve zararlı erişimin durmasıyla değerlendirilir. Bundan sonra 08 numaralı analiz ilerler; yeni bulgu çıkarsa sınırlama kapsamı yeniden genişletilebilir.
Sık hatalar
Yalnızca bir IP engellemek, etkilenen bütün kimlikleri araştırmamak, temiz yönetim cihazı kullanmamak ve sınırlama sonucu test etmemek yaygın hatalardır. Bir başka hata da geçici kuralları unutmak veya kanıt kaydını almadan üretim sistemini biçimlendirmektir. Temizleme ve kalıcı düzeltme, kapsam anlaşıldıkça 09 numaralı adımda planlanır.
08 Kapsamı ve kök nedeni analiz et
Amaç ve araştırılacak sorular
Analiz, olayın nasıl başladığını, nereye yayıldığını ve hangi veriyi veya hizmeti etkilediğini anlamaya çalışır. İyi bir analiz yalnızca zararlı dosya adını bulmaz; ilk giriş, yetki kazanma, kalıcılık, yatay hareket, veri erişimi ve varsa dışa aktarım zincirini inceler. Amaç, saldırganın kullandığı yolları kapatacak ve güvenli kurtarmayı destekleyecek yeterli kanıt sağlamaktır.
Kapsam ve kök neden farklıdır. Kapsam; etkilenen hesap, varlık, veri ve zaman aralığıdır. Kök neden; olayın oluşmasını ve ilerlemesini mümkün kılan temel eksikliktir. Bir kimlik avı e-postası başlangıç yolu olabilir; gereksiz ayrıcalık, zayıf hesap kurtarma veya yetersiz tespit ise zararı büyüten ayrı nedenler olabilir.
İnceleme adımları
1. Delil toplama planını belirleyin. Hangi sistemde hangi kayıt ve geçici bilgi bulunuyor, ne kadar süre saklanıyor ve toplama neyi değiştirebilir? Öncelik, kolay kaybolan ve olayın gidişini açıklayabilecek verilere verilir. Orijinal kayıtlar korunur; analiz mümkün olduğunca uygun kopyalarla yapılır.
2. Olay zaman çizelgesini kurun. İlk şüpheli faaliyet, ilk başarılı erişim, yetki değişikliği, zararlı çalıştırma, veri erişimi ve sınırlama zamanları birleştirilir. Zaman dilimi ve veri boşlukları açıkça gösterilir. İlk alarm zamanı, saldırının başlangıcı olarak varsayılmaz.
3. Giriş yolunu araştırın. Kimlik avı, zafiyet, açık yönetim servisi, çalınmış sır, tedarikçi erişimi veya yanlış yapılandırma gibi hipotezler kanıtla değerlendirilir. Tek bir ihtimale erken bağlanmak diğer giriş yollarını kaçırabilir.
4. Yetki ve kalıcılığı inceleyin. Yeni hesaplar, rol değişiklikleri, görevler, servisler, başlangıç düzenleri, uygulama yetkileri ve bulut erişimleri araştırılır. Saldırganın yeniden erişim sağlayabileceği yollar tespit edilmeye çalışılır.
5. Yatay hareket ve ilişkili varlıkları araştırın. Etkilenen hesabın erişebildiği sistemler, yönetim oturumları ve paylaşımlar incelenir. Aynı gösterge veya davranışın başka cihazlarda bulunup bulunmadığı kontrol edilir. Kapsam, sadece ilk alarmın cihaz listesiyle sınırlanmaz.
6. Veri etkisini belirleyin. Hangi veri görüldü, değişti, silindi veya aktarılmış olabilir? Dışa aktarım ihtimali ile doğrulanmış aktarım ayrılır. Log yetersizliği varsa “veri çıkmadı” gibi kesin bir sonuç verilmez; hangi kanıtın bulunmadığı ve sınırları açıklanır.
7. Kök nedenleri ve katkıda bulunan etkenleri ayırın. Başlangıç açıklığı, aşırı yetki, geç fark edilme, eksik bölümlendirme ve yedek erişim sorunu ayrı aksiyonlar gerektirebilir. Kullanıcı hatasının arkasındaki kontrol ve süreç eksiklikleri de ele alınır.
8. Bulguları düzeltme planına aktarın. Hangi varlıklar yeniden kurulacak, hangi sırlar değişecek, hangi açıklıklar kapanacak ve hangi testler gerekecek? Eksik bilgi varsa kalan belirsizlik ve kabul edilmesi gereken risk ayrıca açıklanır.
Kanıt değerlendirmesi
Her önemli iddia, onu destekleyen kayıt veya inceleme sonucuyla ilişkilendirilir. Doğrulanmış olgu, güçlü hipotez ve henüz araştırılan ihtimal ayrı yazılır. Bir zararlı dosyanın varlığı; çalıştırıldığını, yönetici yetkisi kazandığını veya veri aktardığını tek başına göstermez. Buna karşılık saldırganın logları silmiş olabileceği durumda kayıt yokluğu da meşru faaliyet kanıtı sayılmaz.
Saldırgan kimliğini kesin olarak atfetmek, çoğu operasyonel müdahalede gerekli değildir ve kolay hata yapılabilir. Öncelik; erişim, kapsam, zarar ve düzeltilecek nedenlerdir. Kamuya açık göstergeler yardımcı bilgi olabilir; ortamda doğrulanmadan kesin kanıt gibi kullanılmaz.
Sorumlular ve gerekli kayıtlar
Güvenlik ve gerekiyorsa adli inceleme uzmanları araştırmayı yürütür. BT, uygulama ve bulut sorumluları teknik kayıt sağlar. Hizmet ve veri sahipleri etkiyi doğrular. Hukuk veya kişisel veri sorumluları, bildirim ve delil kullanımındaki gereklilikleri değerlendirir.
Çıktılar; etkilenen varlık listesi, olay zaman çizelgesi, delil envanteri, giriş yolu, kök nedenler, veri etki değerlendirmesi, hipotezler ve düzeltme planıdır. Analiz sırasında yeni erişim yolu görülürse 07 numaralı sınırlama güncellenir. Yeterli kapsam bilgisi sağlandığında 09 numaralı giderme uygulanır; analiz bu aşamada da devam edebilir.
Uygulama örneği ve sık hatalar
Bir sunucuda zararlı süreç bulunması, saldırının yalnızca o sunucuda olduğunu göstermez. Aynı servis hesabının başka sunuculara eriştiği, yönetim aracında yeni görev oluşturduğu ve yedeklere ulaşabildiği anlaşılabilir. Bu bulgu hem kapsamı hem yenilenecek sırları değiştirir.
Sık hatalar; ilk belirtiyi kök neden saymak, son birkaç saati inceleyip eski erişimi kaçırmak, göstergeler dışında davranışa bakmamak ve belirsiz sonuçları kesin raporlamaktır. Analiz, tekrarı önleyecek düzeltmeye yeterli olmalıdır.
09 Tehdidi gider ve açıklığı kapat
Amaç ve sınırlamadan farkı
Giderme, saldırganın bıraktığı bileşenleri ve erişim yollarını kaldırır; olayı mümkün kılan açıklıkları düzeltir. Sınırlama geçici kontrol sağlarken, giderme güvenli işletim için gerekli kalıcı değişiklikleri yapar. Bir zararlı dosyanın silinmesi, saldırganın diğer kalıcılık yollarının ve çaldığı kimliklerin ortadan kalktığı anlamına gelmez.
Düzeltme planı analiz bulgularına dayanır. Etkilenen her varlık için temizleme, yeniden kurma, yapılandırma değişikliği veya tamamen kullanım dışına alma seçeneği değerlendirilir. Güven kaybı yüksekse yalnızca zararlı dosya temizliği yerine güvenilir kaynaktan yeniden kurulum gerekebilir. Kararın teknik ve iş gerekçesi kayıtlı olmalıdır.
Giderme adımları
1. Etkilenen kapsam ve yapılacak işleri netleştirin. Cihaz, hesap, uygulama, bulut kaynağı ve veri düzeltmeleri tek plan içinde ilişkilendirilir. Bir sistemin temizlenip, ona erişen ele geçirilmiş kimliğin açık bırakılması yeniden ihlale yol açabilir.
2. Zararlı ve yetkisiz bileşenleri kaldırın. Doğrulanmış zararlı yazılım, yetkisiz hesap, görev, servis, web bileşeni veya uygulama erişimi giderilir. İşlemden önce gerekli delilin korunduğu ve yapılan değişikliğin kayıtlı olduğu doğrulanır.
3. Gerekiyorsa güvenilir kurulumla yeniden oluşturun. Kaynağın bütünlüğü ve güvenliği doğrulanır, yamalar ve güvenli yapılandırma uygulanır. Eski sistemden yalnızca gerekli ve değerlendirilmiş veriler taşınır. Eski tam görüntüyü kontrol etmeden geri yüklemek, aynı kalıcılığı da geri getirebilir.
4. İlk giriş açıklığını ve katkı nedenlerini düzeltin. Yama, yetki daraltma, yönetim erişimini kapatma, sır yönetimi, uygulama güvenlik düzeltmesi veya MFA güçlendirmesi uygulanabilir. Sadece başlangıç açıklığını düzeltip aşırı yetki ve zayıf izlemeyi bırakmak olay etkisini tekrar mümkün kılabilir.
5. Etkilenmiş sırları güvenli sırayla yenileyin. Parolalar, servis sırları, API anahtarları, uygulama erişimleri ve gerekirse sertifika anahtarları kapsamla birlikte değerlendirilir. Yenileme temiz ve güvenilir yönetim ortamından yapılır. Değişen sırların bağımlı sistemlerde güncellendiği ve eski erişimin kapandığı doğrulanır.
6. Oturum ve yetki kontrollerini tekrar yapın. Aktif oturumlar, tokenlar, delegasyonlar, dış uygulama izinleri ve hesap kurtarma yolları gözden geçirilir. Parola değişiminden sonra geçerli kalan erişim olup olmadığı hizmet davranışına göre test edilir.
7. Geçici sınırlandırmayı koruyarak doğrulama yapın. Açıklık tekrar taranır, yetkisiz görev ve hesaplar araştırılır, ağ ve süreç davranışı incelenir. Kontroller çalışıyor mu, loglar geliyor mu ve yeni bulgu var mı? Güvenlik testleri uygun kapsam ve yetkiyle yürütülür.
Şemadaki başarı kararının uygulanması
“Tehdit giderildi mi ve güvenlik testleri başarılı mı” sorusu, kanıta dayalı bir geçiş koşuludur. Gerekli testlerin kapsamı olay türüne göre önceden belirlenir. Örneğin web ihlalinde güvenlik düzeltmesinin test edilmesi, yetkisiz dosyaların kaldırılması, sırların yenilenmesi ve uygulama loglarının doğrulanması gerekebilir. Hesap ihlalinde oturum, rol ve erişim yollarının kontrolü öne çıkar.
Bir taramanın temiz sonuç vermesi mutlak temizlik garantisi değildir. Testlerin kapsamı, araçların görünürlüğü ve kalan belirsizlik açıklanır. Kritik bulgu giderilmediyse, güvenlik kontrolü çalışmıyorsa veya yeniden erişim kanıtı varsa 08 numaralı analize dönülür ve gerekirse 07 numaralı sınırlama genişletilir.
Sorumlular ve gerekli kayıtlar
BT ile uygulama ekipleri düzeltmeleri, güvenlik ekibi doğrulamayı, hizmet sahibi işlev beklentisini sağlar. Olay lideri planın tamamlığını koordine eder. Gerekli kayıtlar; değişiklik listesi, yeniden kurulum kaynağı, yama ve yapılandırma doğrulaması, sır yenileme kayıtları, test sonuçları ve kalan risklerdir. Sırların kendisi bu kayıtlara yazılmaz.
Başarı ölçütleri; bilinen erişim yollarının kapanması, gerekli kalıcılığın kaldırılması, öncelikli kök nedenlerin düzeltilmesi ve güvenlik testlerinin kabul ölçütlerini karşılamasıdır. Gerekçeli ve yetkili değerlendirmeden sonra 10 numaralı hizmete dönüşe geçilir.
Sık hatalar
Sadece antivirüs temizliğine güvenmek, yama uygulayıp eski ihlali araştırmamak, sırları etkilenmiş cihazdan değiştirmek ve temiz sistemin eski saldırgan erişimiyle yönetilmesi temel hatalardır. Bir başka hata; test başarısızken yalnızca iş baskısıyla sistemi açmaktır. Geri dönüş kararı, iş ihtiyacıyla birlikte kanıt ve kabul edilmiş risk üzerinden verilmelidir.
10 Güvenli biçimde hizmete dön
Amaç ve geri dönüş mantığı
Kurtarma, etkilenen hizmetleri güvenli ve işlevsel biçimde tekrar kullanılabilir hale getirir. Sistemlerin açılması tek başına kurtarma değildir. Veri tutarlılığı, bağımlılıklar, erişimler, izleme ve yeniden ihlal riskinin yönetilmesi birlikte değerlendirilir. Geri dönüş sırası iş etkisi ve hizmet bağımlılıklarına göre belirlenir.
Yedek kullanılması her olayda zorunlu değildir; veri ve sistem durumuna göre yeniden kurulum veya sınırlı veri geri yükleme yeterli olabilir. Kullanılacak yedeklerin ve kurtarma varlıklarının bütünlüğü önceden değerlendirilmelidir. NIST olay müdahalesi rehberi, geri yükleme kaynağının ve kurtarılan sistemlerin doğrulanmasını vurgular. [K2]
Kurtarma hazırlığı
İş etki analizi, hangi hizmetin ne kadar süre kullanılamamasının tolere edilebildiğini ortaya koyar. RTO, hizmetin geri getirilmesi için hedeflenen süredir. RPO, veri kaybı açısından kabul edilebilir geri dönüş aralığını ifade eder. Bu hedefler hizmet sahibince belirlenir; gerçek yedekleme ve kurtarma kapasitesiyle test edilir. Bir hedefin yazılması, o hedefin karşılanabildiğini göstermez. [K7]
Örneğin kayıt işlemleri sık yapılan bir veritabanında günlük yedek, daha kısa veri kaybı beklentisini karşılamayabilir. Yedeklerin sıklığı, tutarlılığı, erişilebilirliği ve geri yükleme hızı birlikte değerlendirilir. Bağımlılıklar yüzünden kimlik, ağ veya depolama hizmeti geri gelmeden uygulamanın açılması mümkün olmayabilir.
Hizmete dönüş adımları
1. Güvenlik geçiş koşullarını doğrulayın. Öncelikli giriş ve kalıcılık yolları kapanmış, gerekli sırlar yenilenmiş ve güvenlik testleri kabul edilmiş olmalıdır. Belirsizlik varsa sınırlı işletim veya ek kontrol ihtiyacı yazılı değerlendirilir.
2. Geri yükleme kaynağını seçin. Olası ilk ihlal zamanı, yedek kapsamı ve veri tutarlılığı dikkate alınır. En yeni yedek, güvenli yedek olmak zorunda değildir. Uygun bütünlük ve zararlı belirti incelemesi yapılır; kaynak hakkında sahip olunan güven açıklanır.
3. Önce izole ortamda geri yükleyin. Uygun olan durumlarda veri ve uygulama üretime bağlanmadan test edilir. Zararlı göstergeler, hesaplar, görevler, erişim izinleri, sürümler ve güvenlik ayarları kontrol edilir. Eski yapılandırmanın açıklığı geri getirmemesi sağlanır.
4. İşlevleri hizmet sahibiyle test edin. Kullanıcı girişi, yetki sınırları, veri okuma ve yazma, raporlar, dış entegrasyonlar ve planlı işler kontrol edilir. Veritabanı tutarlılığı ve eksik işlemler değerlendirilir. Uygulamanın yalnızca ana sayfasının açılması yeterli test değildir.
5. Kademeli açılış planını uygulayın. Önce gerekli bağımlılıklar ve sınırlı kullanıcı veya trafik, sonra geniş işletim devreye alınabilir. Plan; açılış sırası, sorumlular, gözlem süresi, geri alma koşulu ve iletişimi içermelidir.
6. Güvenlik araçlarını ve logları doğrulayın. Yeniden kurulan cihazların envantere girdiği, ajanların çalıştığı ve olayla ilgili tespitlerin aktif olduğu kontrol edilir. İhlalden kalan riskler için izleme kapsamı artırılabilir.
7. Yeniden ortaya çıkma belirtilerini izleyin. Beklenmeyen dış trafik, yeni ayrıcalık, şüpheli süreç veya benzer hata görülürse açılış durdurulur. Gerektiğinde yeniden sınırlama ve analize dönülür. Önceden belirlenen eşik, kararın gecikmesini azaltır.
8. Kullanıcıları ve ilgili tarafları bilgilendirin. Hangi hizmetlerin açıldığı, hangi sınırların sürdüğü ve kullanıcıların ne yapması gerektiği açıklanır. Teknik ayrıntı ve sırlar gereksiz biçimde paylaşılmaz. Kamu veya müşteri açıklamaları yetkili iletişim yoluyla yapılır.
Sorumlular ve gerekli kayıtlar
Kurtarma ekibi teknik geri yüklemeyi, güvenlik ekibi güvenlik doğrulamasını, hizmet sahibi iş kabulünü sağlar. Olay lideri kontrollü açılışı ve geçiş kararlarını koordine eder. Çıktılar; seçilen yedek kaynağı, testler, veri kaybı değerlendirmesi, hizmet açılış sırası, kalan sınırlamalar, geri alma planı ve iş kabul kaydıdır.
Başarı; hizmetin gerekli işlevlerle çalışması, veri tutarlılığının kabul edilmesi, güvenlik kontrollerinin aktif olması ve belirlenen gözlem koşullarında yeniden ihlal belirtisi bulunmamasıyla ölçülür. Kurtarma performansı RTO ve RPO hedefleriyle karşılaştırılır; sapmalar gelecekteki iyileştirmeye aktarılır.
Uygulama örneği ve sık hatalar
Bir uygulama veritabanından geri yüklenmiş olsa bile, dış sistemdeki yeni işlemlerle uyuşmayabilir. Hizmet sahibi hangi kayıtların tekrar işleneceğini belirler; veri ekibi tutarlılığı doğrular. Güvenlik ekibi eski erişim sırlarının kullanılmadığını ve logların geldiğini kontrol eder. Sonra uygulama kademeli açılır.
Sık hatalar; en yeni yedeği kontrol etmeden kullanmak, bütün sistemleri aynı anda açmak, yedekten dönünce eski açıklığı geri getirmek ve iş kabulünü atlamaktır. Güvenli kurtarma tamamlandığında olay 11 numaralı kapanış ve iyileştirmeye geçer.
11 Kapat öğren ve iyileştir
Amaç ve kapanış koşulları
Kapanış, olayın hangi sonuçla tamamlandığını ve kalan işlerin kim tarafından yürütüleceğini netleştirir. Olay kaydının kapatılması, bütün uzun vadeli risklerin ortadan kalktığı anlamına gelmez. Acil tehdit kontrol altına alınmış, kurtarma kabul edilmiş ve kalan aksiyonlar sorumlu ile tarihe bağlanmış olmalıdır. Olay ve iyileştirme görevleri ayrı takip edilebilir, ancak birbirleriyle bağlantılı kalır.
İyileştirme; tespitin neden geciktiği, kapsamın nasıl büyüdüğü, hangi kontrolün işe yaradığı ve hangi kararın müdahaleyi yavaşlattığı sorularını ele alır. Amaç kişisel suçlama yerine sistemi geliştirmektir. Saptanan açık kritikse, değerlendirme toplantısını beklemeden düzeltme başlatılır.
Kapanış ve değerlendirme adımları
1. Kapanış ölçütlerini kontrol edin. Öncelikli tehditler ve erişim yolları giderilmiş mi, hizmet sahibi kurtarmayı kabul etmiş mi, gerekli kayıtlar tamam mı, bildirim gereği değerlendirilmiş mi? Kalan risk ve belirsizlikler yetkili kişi tarafından sahiplenilir.
2. Olay raporunu tamamlayın. Kısa yönetim özeti, teknik zaman çizelgesi, etkilenen varlık ve veri, giriş yolu, kök neden, yapılan işlemler, iş etkisi ve kurtarma sonucu bulunur. Doğrulanmış bilgiler ile sonuçlandırılamamış değerlendirmeler ayrı gösterilir.
3. Müdahale sonrası değerlendirme yapın. Bildirim, ilk inceleme, sınırlama, analiz, giderme ve kurtarma süreçleri karşılaştırılır. Hangi veri eksikti, hangi yetki bekleniyordu, hangi araç işe yaramadı? Çalışanların sahadaki deneyimi de dikkate alınır.
4. Aksiyonları ölçülebilir hale getirin. “Güvenliği artır” yerine “kritik yönetici hesaplarının uygun MFA kapsamını tamamla ve giriş testiyle doğrula” gibi açık görevler yazılır. Her görevin sahibi, hedef tarihi, önceliği ve tamamlanma kanıtı bulunur.
5. Envanter ve risk listesini güncelleyin. Yeni keşfedilen varlıklar 01 numaralı adıma, değişen riskler 02 numaralı adıma aktarılır. Yeni kontroller 03, yeni tespitler 04, müdahale planları ise 05 ve sonraki adımlara yansıtılır.
6. Geçici önlemleri değerlendirin. Acil açılan hesaplar, izolasyonlar, engelleme kuralları ve istisnalar tek tek gözden geçirilir. Gerekenler kalıcı kontrol olarak onaylanır; diğerleri kayıtlı biçimde kaldırılır. Kaldırma, saldırgan erişimini geri getirmemelidir.
7. Kayıtları ve delilleri uygun biçimde saklayın. Erişim yetkileri, saklama gerekçesi ve süreleri belirlenir. Süre sonunda güvenli silme veya arşiv düzeni işletilir. Olay raporunun kendisi de hassas bilgi içerdiği için korunmalıdır.
8. İyileştirmeyi yeniden test edin. Aynı saldırı belirtisi kontrollü biçimde üretildiğinde tespit, iletişim ve sınırlama çalışıyor mu? Yeni prosedürün ekip tarafından gerçekten uygulanabildiği tatbikatla doğrulanır.
Ölçütler
Tespit, ilk inceleme, sınırlama ve kurtarma süreleri ölçülebilir. Ölçümün başlangıç ve bitişi açık tanımlanır; bilinmeyen saldırı başlangıcı kesin kabul edilmez. Ortalama sürelerin yanında olay önemi ve iş etkisi değerlendirilir. Basit alarmların hızla kapanması, az sayıdaki kritik olayın yavaş ele alınmasını gizlememelidir.
Diğer ölçütler; tekrar eden olaylar, tamamlanmamış kök neden aksiyonları, veri kaybı, hedefi aşan kesinti, yanlış alarm eğilimi ve tatbikat başarısıdır. Veriler iyileştirme kararını desteklemelidir; yalnızca iyi görünmek için metrik seçilmez.
Sorumlular ve çıktılar
Olay lideri rapor ve kapanışı koordine eder. Teknik ekipler kanıt ve düzeltme sonucunu sağlar. Hizmet sahibi iş etkisini, yönetim kalan risk ve kaynak kararını değerlendirir. Çıktılar; kapanış onayı, olay raporu, iyileştirme planı, güncellenen risk ve kontrol kayıtları, tatbikat sonucu ve arşivlenen delillerdir.
Bir sonraki döngü, yeni envanter ve risk bilgisiyle tekrar başlar. Güvenlik bu nedenle doğrusal bir proje değil, işletilen bir yönetim sürecidir.
Uygulama örneği ve sık hatalar
Bir olayda loglara geç ulaşılması sınırlamayı geciktirmişse, yalnızca daha fazla log depolamak yeterli çözüm olmayabilir. Kritik kaynakların merkezi erişimi, mesai dışı yetkiler ve alarm sahipliği düzeltilir. Sonraki tatbikatta aynı kayıtların zamanında kullanılabildiği test edilir.
Sık hatalar; hizmet açıldıktan sonra raporu bırakmak, aksiyonlara tarih vermemek, aynı olayı tekrarlayan süreçleri değiştirmemek ve kişiyi suçlayıp kontrol sorununu görmezden gelmektir. Kapanışın değeri, bir sonraki olayda daha güçlü hazırlık ve daha etkili müdahale sağlamasıdır.
Ekler ve uygulama araçları
Ek A Rol ve sorumluluk matrisi
Aşağıdaki görevler bir başlangıç modelidir. Küçük ekiplerde görevler birleştirilebilir, ancak sahiplik, vekalet ve kritik kararların onayı korunmalıdır.
| Rol | Temel sorumluluk | Önemli karar veya çıktı |
| Üst yönetim | Risk toleransı ve kaynak sağlamak | Risk kabulü ve öncelik kararları |
| Güvenlik sorumlusu | Süreç, risk ve kontrol koordinasyonu | Politika, risk planı, performans takibi |
| Olay lideri | Olay sırasında işleri koordine etmek | Öncelik, sınırlama ve geçiş koordinasyonu |
| BT ve platform ekipleri | Cihaz, ağ, kimlik ve yedekleri işletmek | Yapılandırma, izolasyon, geri yükleme |
| Uygulama ve geliştirme ekibi | Uygulama ile bağımlılıkları düzeltmek | Güvenlik düzeltmesi ve işlev testleri |
| Hizmet ve veri sahipleri | İş etkisi ve veri ihtiyacını belirlemek | Kritikliği ve hizmete dönüşü kabul etmek |
| Hukuk ve veri sorumluları | Geçerli bildirim ve kayıt gereğini değerlendirmek | Yükümlülük ve bildirim değerlendirmesi |
| İletişim sorumlusu | Onaylı ve tutarlı bilgi paylaşmak | Yönetim, çalışan ve müşteri açıklamaları |
| Dış hizmet sağlayıcı | Sözleşmedeki teknik desteği sağlamak | Log, erişim, düzeltme ve kurtarma desteği |
Ek B Örnek olay önem seviyeleri
Bu sınıflar kuruma göre uyarlanır. Seviye, alarm aracının puanından ayrı değerlendirilir. Yanıt süreleri burada evrensel bir süre olarak verilmemiştir; kurum bunları hizmet kritikliğine, personel kapasitesine ve yükümlülüklerine göre onaylamalıdır.
| Seviye | Örnek durum | Yönetim yaklaşımı |
| Kritik | Aktif şifreleme, kritik kimlik ihlali, ağır veri etkisi veya çoklu kritik kesinti | Acil koordinasyon, yetkili sınırlama, yönetim bilgilendirmesi |
| Yüksek | Doğrulanmış yetkisiz erişim veya kritik varlıkta zararlı faaliyet | Hızlı müdahale, kapsam analizi ve yakın takip |
| Orta | Sınırlı etki, kontrol altındaki yerel olay veya araştırılması gereken ciddi şüphe | Atanmış sorumlu, planlı inceleme ve koşullu yükseltme |
| Düşük | Düşük iş etkili belirti veya değerlendirme bekleyen sınırlı bulgu | Kayıtlı inceleme, sonuçlandırma ve kural iyileştirme |
Bir olay seviyesini; yeni etkilenen varlık, yönetici erişimi, veri aktarımı, güvenlik kontrolünün kapanması veya hizmet kaybı yükseltebilir. Yüksek etki ihtimali olan belirsiz durumda veri eksikliği, düşük öncelik gerekçesi olarak tek başına kullanılmaz.
Ek C Asgari kayıt alanları
Varlık kaydı; benzersiz kimlik, isim, tür, ortam, IP veya alan adı, teknik sahip, iş sahibi, sürüm, destek durumu, veri sınıfı, kritik hizmet bağlantısı, dışa açıklık, güvenlik aracı durumu, yedek kapsamı ve son doğrulama tarihini içerir. Hesap kaydında insan veya servis hesabı ayrımı, amaç, sahip, ayrıcalıklar ve gözden geçirme bilgisi bulunur.
Risk kaydı; risk kimliği, senaryo, varlık veya hizmet, tehdit, zafiyet, olasılık, iş etkisi, değerlendirme gerekçesi, mevcut kontroller, kanıtlar, işleme seçeneği, aksiyon sahibi, hedef tarih, kalan risk, kabul eden kişi ve gözden geçirme tarihini içerir. Sayısal puan kullanılıyorsa yöntem ve ölçek açıklaması kayıtla ilişkilendirilir.
Olay kaydı; olay kimliği, bildirim kaynağı, tespit ve bildirim zamanları, ilk sorumlu, lider, kategori, önem seviyesi, doğrulama durumu, etkilenen varlıklar, veri etkisi, kanıt bağlantıları, zaman çizelgesi, hipotezler, değişiklikler, onaylar, iletişim, kurtarma testleri, kalan risk ve kapanış sonucunu içerir. Parola, token veya gizli anahtar kayda yazılmaz.
Delil kaydı; delil kimliği, kaynak, toplama zamanı ve saat dilimi, toplayan kişi, kullanılan araç veya yöntem, yapılan işlemler, uygun bütünlük doğrulaması, depolama yeri, erişim yetkisi ve gerektiğinde teslim zincirini içerir. Kopya üzerinde yapılan analiz, orijinalin korunma düzeninden ayrılır. Delilin kimden, ne zaman ve hangi koşullarda geldiği izlenebilir olmalıdır.
Değişiklik kaydı; amaç, kapsam, etkilenen hizmetler, uygulayan kişi, yetki veya onay, uygulama zamanı, test sonucu, geri alma yöntemi ve geçici ise sona erme koşulunu içerir. Acil değişikliklerde de sonradan tamamlanan kayıtlar olayla bağlantılı tutulur.
Ek D Hazırlık ve müdahale kontrol listeleri
Hazırlık kontrol listesi
- Kritik hizmetler, teknik sahipleri ve iş sahipleri belirli mi?
- Varlık, veri, hesap ve bağımlılık envanteri güncel mi?
- Öncelikli riskler ve açık aksiyonlar sahipli ve tarihli mi?
- Yönetici ve uzaktan erişim hesapları uygun kimlik doğrulamayla korunuyor mu?
- Güncelleme, güvenli yapılandırma ve ayrıcalık kontrolü doğrulanıyor mu?
- Yedekler üretim erişiminden yeterince korunuyor ve geri yükleme test ediliyor mu?
- Kritik loglar geliyor, korunuyor ve kesilmeleri fark ediliyor mu?
- Alarmın sahibi, mesai dışı yükseltmesi ve alternatif iletişim yolu belli mi?
- Müdahale yetkileri, delil koruma ve kurtarma planları test edildi mi?
- Tedarikçi erişimleri ve olay destek koşulları açık mı?
Olayın ilk değerlendirmesi
- Olay kaydı ve ilk sorumlu atandı mı?
- Devam eden zarar ve kritik hizmet etkisi değerlendirildi mi?
- Alarmın ham verisi ve iş bağlamı kontrol edildi mi?
- Gerekli kısa ömürlü kayıtlar korunuyor mu?
- Sonuç; doğrulanmış olay, gerekçeli yanlış alarm veya açık şüphe olarak ayrıldı mı?
- Sınırlama gerekiyorsa yetki, kapsam ve hizmet etkisi kayda alındı mı?
- Ekip güvenilir yönetim cihazı ve uygun iletişim kanalı kullanıyor mu?
Giderme ve hizmete dönüş kontrolü
- İlk giriş ve kalıcılık yolları yeterli kapsamda araştırıldı mı?
- Etkilenen hesap, cihaz ve veriler plan içinde ele alındı mı?
- Gereken sırlar ve oturum erişimleri yenilendi veya kaldırıldı mı?
- Gerekli düzeltmeler testle doğrulandı mı?
- Geri yükleme kaynağı ve veri tutarlılığı kontrol edildi mi?
- İşlev, yetki ve güvenlik testleri kabul ölçütlerini karşılıyor mu?
- Loglar ve güvenlik araçları yeni ortamda çalışıyor mu?
- Kademeli açılış, gözlem ve geri alma koşulları belli mi?
- Hizmet sahibi kabulü ve kalan risk kararı kayıtlı mı?
- Kapanış raporu ile tarihli iyileştirme aksiyonları hazır mı?
Ek E Süreçlerin birlikte işlemesine örnek
Bir kurumun müşteri portalında yönetici hesabıyla beklenmedik giriş alarmı oluştuğunu düşünün. İzleme sistemi, yeni cihazdan girişin ardından olağan dışı veri indirmesini görür. 04 numaralı adım alarm üretir; 05 numaralı adım kayıt ve sorumlu atamasını başlatır. 06 numaralı adımda bakım olmadığı, hesabın sahibi tarafından işlem yapılmadığı ve bağımsız kayıtlarda aynı oturumun görüldüğü doğrulanır. Olayın önemi veri etkisi ve ayrıcalık nedeniyle yükseltilir.
07 numaralı adımda ilgili erişim ve oturumlar sınırlanır; yedekler ve diğer kritik sistemler korunur. 08 numaralı adımda zaman çizelgesi, hesap kurtarma değişikliği ve başka hizmetlere erişim araştırılır. Şüpheli bir dış uygulama izni bulunduğunda sınırlama güncellenir. Veri çıkışının kapsamı, erişim ve aktarım kayıtlarıyla değerlendirilir; görülemeyen bölümler ayrıca belirtilir.
09 numaralı adımda yetkisiz izin kaldırılır, gerekli kimlik sırları güvenli ortamdan yenilenir ve kurtarma süreci düzeltilir. Oturum testleri başarısızsa analiz ve giderme tekrarlanır. Başarı koşulları sağlandığında 10 numaralı adımda hizmet sahibiyle yetki ve işlev testleri yapılarak portal kademeli açılır. 11 numaralı adımda rapor tamamlanır; risk kaydı, kimlik kontrolleri ve tespit senaryoları güncellenir. Bu örnekte yedekten geri dönüş gerekmeyebilir; kurtarma seçeneği gerçek veri ve sistem etkisine göre belirlenir.
Ek F Düzenli gözden geçirme ve tatbikat
Gözden geçirme sıklığı risk ve değişim hızına göre belirlenir. Sürekli izlenmesi gereken kaynak sağlığı ile dönemsel politika incelemesi aynı sıklıkta yürütülmez. Yeni varlık, görev değişikliği, büyük sürüm geçişi, önemli tehdit bilgisi, başarısız geri yükleme veya olay sonrası ek değerlendirme yapılır. Her tekrarın amacı ve sahibi kayıtlı olmalıdır.
Masa başı tatbikatta ekip, örnek olay üzerinden görev ve kararları konuşur; gerçek sistem değişikliği yapılmayabilir. Teknik tatbikatta uygun kapsam ve yetkiyle tespit, izolasyon veya geri yükleme test edilir. Her ikisinin sonucu; eksik iletişim, erişilemeyen kayıt, belirsiz yetki ve başarısız test gibi bulguları aksiyona dönüştürmelidir.
Tatbikatın başarısı, senaryonun sunulmasıyla ölçülmez. Ekip alarmı görebiliyor, yeterli kaydı bulabiliyor, yetkili sınırlama yapabiliyor ve hizmeti test ederek geri döndürebiliyorsa süreç uygulanabilir durumdadır. Başarısız noktalar kontrol sahibi ve tarihle takip edilir.
Ek G Bildirim ve hassas bilgi yönetimi
Olay sırasında hangi tarafın hangi bilgiye ihtiyaç duyduğu belirlenir. Teknik ekip kanıt ve işlem ayrıntısını, yönetim iş etkisi ile karar ihtiyacını, çalışanlar güvenli kullanım talimatını, müşteriler hizmet durumu ve ilgili aksiyonları öğrenmelidir. Aynı ayrıntıyı herkese göndermek hem bilgi yükü hem gereksiz hassas bilgi paylaşımı oluşturabilir.
Kişisel veri, düzenlenmiş hizmet, sözleşme veya sigorta etkisi varsa ilgili sorumlular bildirim gereğini ve sürelerini geçerli kurallar üzerinden değerlendirir. Bütün olaylar için tek bir evrensel bildirim süresi varsayılmaz. Bilgi kesinleşmediğinde doğrulanmış gerçekler, belirsizlikler ve bir sonraki güncelleme zamanı açıkça ifade edilir. Resmi veya dış açıklamalar yetkili kişilerce onaylanır.
Olay raporunda IP, kullanıcı adı, sistem yapısı, açıklık ve delil bulunabilir. Paylaşılan kopyada ihtiyaç dışı ayrıntılar çıkarılabilir, ancak asıl kayıt uygun erişim düzeninde korunur. Herkese açık dosya analizi veya destek platformuna hassas örnek yükleme, ayrıca değerlendirilmesi gereken bir veri paylaşımıdır.
Ek H Kısa terim sözlüğü
| Terim | Açıklama |
| MFA | Çok faktörlü kimlik doğrulama; farklı faktör türleriyle giriş doğrulaması |
| SIEM | Güvenlik loglarını merkezi toplama, arama ve ilişkilendirme düzeni |
| EDR | Uç nokta davranışlarını tespit ve araştırma ile bazı yanıt işlemlerini sağlayan teknoloji |
| IDS ve IPS | Sırasıyla ağ saldırısı belirtisi tespiti ve uygun eşleşmelerde önleme işlevleri |
| WAF | Web uygulamasına yönelik istekleri belirli kurallarla inceleyen güvenlik katmanı |
| DDoS | Çoklu kaynak üzerinden hizmetin kapasitesini veya erişilebilirliğini tüketen saldırı |
| IoT ve OT | Bağlı cihazlar ile fiziksel süreçleri izleyen veya kontrol eden işletme teknolojileri |
| IOC | İhlalle ilişkili olabilecek dosya, adres veya benzeri teknik gösterge |
| TTP | Saldırganın taktik, teknik ve prosedürleri; davranışın nasıl yürütüldüğü |
| RTO | Bir hizmetin geri getirilmesi için hedeflenen kurtarma süresi |
| RPO | Veri kaybı açısından kabul edilen geri dönüş aralığı |
| Yatay hareket | Ele geçirilen erişimin başka sistemlere ulaşmak için kullanılması |
| Kalıcılık | Saldırganın tekrar erişim sağlayabilmesi için bıraktığı mekanizma |
| Kalan risk | Kontroller ve düzeltmelerden sonra devam eden risk |
| Zincirleme teslim kaydı | Delilin kimler arasında, ne zaman ve nasıl el değiştirdiğinin kaydı |
Erdem Uluğ