Varlık Bazlı mı, Senaryo Bazlı mı? Risk Değerlendirmesi Seçimi

Altı yüz satırlık bir risk kaydı açıyorsunuz ve satırların çoğu aynı tehdit, aynı puan, aynı “mevcut kontrol” cümlesiyle kopyalanmış. Yönetim toplantısında bu tablodan tek bir karar çıkmıyor. ISO/IEC 27001:2022 risk değerlendirmesinin nasıl yapılacağını dayatmaz; yalnızca tutarlı, geçerli ve karşılaştırılabilir sonuç üreten, tekrarlanabilir bir süreç ister. Bu serbestlik iki yolu açar: varlık bazlı ve senaryo bazlı değerlendirme. Aşağıda BGYS sorumluları ve risk yöneticileri için iki yaklaşımı iş yükü, yakaladığı riskler, yönetime anlatılabilirlik ve denetim kabulü açısından karşılaştırıyoruz; aynı ortamdan iki yöntemle çıkarılmış örnek satırlar ve hibrit model için bir karar sırası da var.

İki yaklaşımın mantığı

ISO/IEC 27005:2022 risk tanımlamada iki yolu açıkça tarif eder: varlık tabanlı (asset-based) ve olay tabanlı (event-based) yaklaşım. Sahada olay tabanlı yaklaşıma genellikle “senaryo bazlı” denir. Fark, analizin hangi soruyla başladığındadır.

Varlık bazlı yaklaşım

Başlangıç noktası bilgi varlığı envanteridir. Her varlık veya varlık grubu için şu soru sorulur: “Bu varlığa hangi tehdit, hangi zafiyetten yararlanarak zarar verebilir?” Çıktı, varlık–tehdit–zafiyet üçlülerinden oluşan ayrıntılı ama kalabalık bir kayıttır. ISO/IEC 27001:2005 bu yaklaşımı fiilen zorunlu tutuyordu; 2013 sürümüyle varlık tanımlaması şart olmaktan çıktı ve risk değerlendirmesi ISO 31000 mantığına yaklaştırıldı. Pek çok kuruluşun risk kaydının hâlâ varlık bazlı olmasının nedeni bu tarihsel miras. Yöntem bilinçli seçilmemiş, devralınmıştır.

Senaryo bazlı yaklaşım

Başlangıç noktası, kuruluşun hedeflerini etkileyebilecek olaylardır: “Fidye yazılımı üretim planlama sistemlerini şifreler, yedekler de etkilenir”, “Bir tedarikçinin uzaktan erişim hesabı ele geçirilir”, “Müşteri çizimleri yetkisiz bir buluta yüklenir”. Her senaryo risk kaynağını, olay zincirini ve iş sonucunu birlikte anlatır. Etkilenen varlıklar senaryonun içinde listelenir ama analizin birimi varlık değil olaydır. NIST SP 800-30 Rev. 1’deki tehdit odaklı (threat-oriented) analiz de aynı mantığa dayanır.

Karşılaştırma tablosu

Kriter	Varlık bazlı	Senaryo bazlı
Girdi	Ayrıntılı varlık envanteri	İş süreçleri, tehdit istihbaratı, olay geçmişi
Risk kaydı hacmi	Yüksek; yüzlerce satır olağan	Düşük; onlarca senaryo
İlk kurulum emeği	Yüksek, mekanik	Orta, uzman yargısı gerektirir
Yönetime anlatım	Zor; ağaçtan orman görünmez	Kolay; iş diliyle konuşur
Kapsam boşluğu riski	Düşük; her varlık taranır	Orta; akla gelmeyen senaryo atlanır
Zincirleme etkiler	Zayıf; varlıklar ayrı ayrı ele alınır	Güçlü; olay zinciri bütün görülür
Kontrol eşleme	Teknik kontrollere doğrudan bağlanır	Birden fazla kontrol katmanını birlikte gösterir
Güncelleme	Varlık değiştikçe sürekli bakım ister	Tehdit ortamı değiştikçe gözden geçirilir

Denetim kabulü açısından iki yaklaşım da geçerlidir. Belgelendirme denetçisi yöntemin adına bakmaz; ISO/IEC 27001 madde 6.1.2’nin karşılanıp karşılanmadığına bakar: risk kriterleri tanımlı mı, riskler sahiplendirilmiş mi, olasılık ve sonuç değerlendirilmiş mi, aynı süreç tekrar uygulandığında benzer sonuç çıkıyor mu? Senaryo bazlı kayıtta denetçinin ilk sorusu genellikle “Bu senaryolar kapsamın tamamını temsil ediyor mu?” olur. Varlık bazlı kayıtta soru değişir: “Bu kadar satırın hangisi gerçekten yönetiliyor?”

Aynı ortamdan örnek risk satırları

Farkı görmek için kurgusal bir ortam alalım: tek lokasyonlu, ERP ve MES çalıştıran, yedeği şirket içindeki bir NAS’a ve ayrıca bulut depolamaya alan orta ölçekli bir üretim şirketi. Olasılık ve etki 1–5 ölçeğinde, risk puanı olasılık × etki. Değerler örnek amaçlıdır.

Varlık bazlı satırlar

Varlık	Tehdit / zafiyet	O × E
ERP veritabanı sunucusu	Zararlı yazılım / gecikmiş yamalar	3 × 5 = 15
Dosya sunucusu	Zararlı yazılım / geniş paylaşım izinleri	3 × 4 = 12
Yedekleme NAS’ı	Yetkisiz erişim / domain hesabıyla yönetim	2 × 4 = 8
MES uygulama sunucusu	Hizmet kesintisi / tek sunucu	2 × 5 = 10

Senaryo bazlı satır

Senaryo	Etkilenen varlıklar	O × E
Kimlik avıyla ele geçirilen bir hesap üzerinden fidye yazılımı yayılır; domain’e bağlı NAS’taki yedekler de şifrelenir, ERP ve MES günlerce çalışmaz	ERP, MES, dosya sunucusu, NAS, Active Directory	3 × 5 = 15

Varlık bazlı kayıtta NAS satırı tek başına “8 – orta” görünür ve önceliklendirmede geriye düşer. Senaryo bazlı satır ise asıl sorunu ortaya koyar: yedekler üretim ortamıyla aynı kimlik altyapısından yönetildiği için, ERP’deki fidye yazılımı riski kurtarılamaz hale gelir. Sahada en sık gördüğümüz tablo budur. Domain’e üye NAS, domain admin hesabıyla açılan yönetim arayüzü, aynı ağ segmentinde duran yedek hedefi. Kâğıtta yedek var. Gerçekte saldırgan için ikinci bir hedef var.

Öte yandan varlık bazlı kayıt, senaryo atölyesinde hiç konuşulmamış “MES tek sunucu” zafiyetini yakalamıştır. Atölyedekiler fidye yazılımına odaklanmış, donanım arızasını atlamıştır. Bir yöntemin kör noktası öbürünün güçlü yanıdır.

Hangi durumda hangisi? Karar sırası

Metodoloji seçerken şu soruları sırayla yanıtlayın:

1. Güncel ve sahipleri belli bir varlık envanteriniz var mı? Yoksa varlık bazlı yaklaşım ilk yılı envanter çalışmasına harcatır. Senaryo bazlı başlayın, envanteri paralelde olgunlaştırın.
2. Risk sonuçlarını kim kullanacak? Üst yönetim ve yönetim kurulu ise senaryo bazlı çıktı gerekir. Ana kullanıcı teknik ekipler ve kontrol sahipleriyse varlık düzeyinde ayrıntı işe yarar.
3. Müşteri veya düzenleyici varlık düzeyinde kanıt istiyor mu? Müşteri denetimlerinde belirli sistemler için ayrı risk değerlendirmesi isteniyorsa, en azından o sistemler için varlık düzeyinde satır tutun.
4. Ortam ne kadar homojen? Yüzlerce benzer uç nokta ve sunucu varsa varlık gruplarıyla çalışmak zorunlu hale gelir; tek tek varlık satırı sürdürülemez.
5. Riski değerlendirecek deneyimli bir ekip var mı? Senaryo bazlı yöntemin kalitesi atölyedeki insanların bilgisine bağlıdır. Deneyim sınırlıysa varlık bazlı kontrol listesi yaklaşımı daha az şey atlar.

Yanıtların çoğu senaryo tarafını gösteriyor ama 3. veya 5. soruda varlık tarafı çıkıyorsa, hibrit model en makul seçenektir.

Hibrit yaklaşım

Hibrit modelde iki katman vardır ve birbirine açık referansla bağlanır:

• Üst katman – senaryo kaydı: Yönetimin tek toplantıda tartışabileceği sayıda senaryo. Risk sahibi süreç veya iş birimi yöneticisidir; risk iştahı ve risk kabul kriterleri bu katmanda uygulanır.
• Alt katman – kritik varlık grupları: Senaryolarda adı geçen ve gizlilik, bütünlük veya erişilebilirlik değeri yüksek varlık grupları için tehdit–zafiyet analizi. Bu katman teknik kontrol eksiklerini yakalar ve senaryo olasılığına gerekçe verir.
• Bağlantı: Her varlık bazlı satır en az bir senaryoya bağlanır. Hiçbir senaryoya bağlanamayan yüksek puanlı varlık satırı, eksik bir senaryonun işaretidir.

Bu kurguda bilgi varlığı envanteri “her şeyin listesi” olmaktan çıkar; senaryoların hangi varlıklara dokunduğunu gösteren referans tablosuna dönüşür. Kapsam boşluğunu daraltmak için senaryo listesini yılda bir kez ISO/IEC 27002:2022 kontrol temalarına ve son dönemdeki olay kayıtlarına karşı çapraz kontrol edin. Olay kaydında geçen ama hiçbir senaryoda karşılığı olmayan bir başlık, eksik senaryodur.

Sahada sık görülen hatalar

• Varlık bazlı kaydı “tamamlanmış” saymak: Yüzlerce satırın büyük kısmı aynı tehdit ve aynı puanla kopyalanmışsa değerlendirme yapılmamış, şablon doldurulmuştur. Denetçi bunu iki satıra bakınca anlar.
• Senaryoları tehdit adıyla sınırlamak: “Fidye yazılımı”, “DDoS”, “İç tehdit” gibi başlıklar olasılık ve etki tartışmasına zemin vermez. Başlık senaryo değildir.
• Olasılığı gerekçesiz vermek: Puanın yanında mevcut kontroller ve olay geçmişi yazılmazsa, gelecek yıl aynı puanı kimse açıklayamaz. Atölyede “3 verelim” denip geçilen puan, bir sonraki gözden geçirmede tartışmayı baştan başlatır.
• Yöntem değişince eski riskleri sessizce silmek: Denetçi önceki kayıtta yer alan yüksek riskin nereye gittiğini sorar. Cevap hazır olmalıdır.

Metodoloji değişikliğinde geçiş

Varlık bazlı kayıttan senaryo bazlı veya hibrit modele geçiş, BGYS’de planlı bir değişikliktir ve ISO/IEC 27001 madde 6.3 kapsamında ele alınır. Pratik geçiş sırası:

1. Metodoloji dokümanını güncelleyin: Risk tanımlama birimi, ölçekler, kabul kriterleri ve gözden geçirme sıklığı yazılı olsun; yönetim onayını alın.
2. Eşleme tablosu hazırlayın: Eski kayıttaki her satırı yeni senaryolardan birine bağlayın. Bağlanamayan satır ya yeni bir senaryo gerektirir ya da gerekçesiyle kapatılır.
3. Açık aksiyonları taşıyın: Eski risklere bağlı işleme aksiyonları yeni senaryolara aktarılır; risk işleme planı geçiş sırasında kesintiye uğramamalıdır.
4. SoA gerekçelerini kontrol edin: Uygulanabilirlik Bildirgesi’nde kontrol gerekçesi olarak eski risk numaraları geçiyorsa güncelleyin. Bu adım en sık unutulandır.
5. Eski kaydı arşivleyin: Silmeyin; onay tarihiyle birlikte salt okunur saklayın. Bir sonraki denetimde geçişin izlenebilirliği bu arşivle gösterilir.
6. Risk sahiplerini yeniden onaylatın: Senaryo bazlı modelde risk sahipleri genellikle değişir; kalıntı risk kabulü yeni sahipler tarafından yeniden verilir.

Süreç adımlarının uçtan uca bir örneği için BGYS risk analizi örnek süreci rehberine bakabilirsiniz. Metodolojinin kuruluşa göre tasarlanması ve mevcut risk kaydının dönüştürülmesi, kurumsal bilgi güvenliği risk değerlendirmesi ve ISO 27001 risk analizi ve SoA çalışmalarının konusudur. Yöntem için birincil kaynak ISO/IEC 27005:2022 standardıdır.

Sık sorulan sorular

ISO 27001 varlık bazlı risk değerlendirmesini zorunlu tutuyor mu?

Hayır. ISO/IEC 27001:2013 ile varlık tanımlaması risk değerlendirmesinin zorunlu başlangıç noktası olmaktan çıktı; 2022 sürümü de yalnızca tutarlı, geçerli ve karşılaştırılabilir sonuç üreten tanımlı bir süreç ister. Varlık envanteri ise Annex A 5.9 kontrolü kapsamında ayrıca beklenir.

Senaryo bazlı yaklaşımda kaç senaryo yeterlidir?

Sabit bir sayı yok. Ölçüt, senaryoların kapsamdaki kritik süreçleri ve önemli tehdit kaynaklarını temsil etmesi ve yönetimin bunları gerçekten tartışabilmesidir. Senaryo listesini kontrol temaları ve olay geçmişiyle çapraz kontrol ederek boşluk kalıp kalmadığını test edin.

Hibrit yaklaşımda risk kabulü hangi katmanda yapılır?

Kabul kararı genellikle senaryo katmanında, iş tarafındaki risk sahibi tarafından verilir. Varlık katmanındaki satırlar senaryonun olasılık ve etki gerekçesini destekler; ayrı kabul yalnızca kendi başına kabul eşiğini aşan riskler için gerekir.

Metodoloji değişikliği belgelendirme denetiminde sorun yaratır mı?

Değişiklik planlı yapılmış, metodoloji dokümanı onaylanmış ve eski kayıtla yeni kayıt arasında izlenebilir bir eşleme varsa sorun yaratmaz. Eski yüksek risklerin nereye taşındığını gösteremeyen geçiş ise bulgu riskini artırır.