Temel yaklaşım
Bilgi güvenliği riski
neyi ifade eder?
Bilgi güvenliği riski, bir olayın bilgi varlıklarının gizliliği, bütünlüğü veya erişilebilirliği üzerinde olumsuz sonuç oluşturma ihtimaliyle ilgilidir. Risk yalnız teknik açık değildir. Hatalı yetkilendirme, insan hatası, tedarikçi bağımlılığı, fiziksel olay, süreç boşluğu, doğal afet veya kasıtlı saldırı; kuruluşun hedeflerini etkileyen risk senaryolarına dönüşebilir.
ISO/IEC 27001:2022 ve Amd 1:2024 güncel gereklilik çerçevesini; ISO/IEC 27005:2022 ise bilgi güvenliği risk yönetimi için ayrıntılı rehberliği sağlar. Kullanılacak yöntem kuruluşun büyüklüğüne, bilgi yoğunluğuna, mevzuatına, müşterilerine ve teknoloji yapısına göre uyarlanmalıdır.
Bu konuyu kuruluşunuzda uygulamaya taşımak için ISO/IEC 27001 yaklaşımımızı inceleyebilirsiniz.
Kavramlar
Varlık, tehdit, zafiyet ve
risk arasındaki fark
- Varlık: Kuruluş için değer taşıyan bilgi, süreç, insan, teknoloji, tesis, hizmet veya ilişkidir.
- Tehdit / risk kaynağı: Zarara yol açabilecek kişi, olay, durum veya etkendir.
- Zafiyet: Bir tehdidin etkili olmasını kolaylaştırabilecek eksiklik veya zayıflıktır.
- Olay: Risk senaryosunun gerçekleşen veya gerçekleşmeye yaklaşan hâlidir.
- Sonuç: Olayın iş, müşteri, yasal uyum, itibar, finans veya operasyon üzerindeki etkisidir.
- Risk: Olası olay ve sonuçların, kuruluşun belirlediği kriterlere göre değerlendirilmesidir.
Varlık-tehdit-zafiyet yaklaşımı kullanışlıdır; ancak ISO/IEC 27001'in zorunlu kıldığı tek model değildir. Kuruluş, iş süreçlerinden ve istenmeyen olay senaryolarından başlayan bir yöntem de kullanabilir. Önemli olan kapsamın tamamını gören ve aynı koşullarda benzer sonuç üreten bir süreç kurmaktır.
Uygulama yaklaşımı
Kontrol listesinden önce,
risk senaryosunu kurun.
Bilgi güvenliği riskleri; süreç, varlık, tehdit, zafiyet ve iş etkisi arasındaki bağlantıyla tanımlanmalı; kontroller bu gerekçeden türetilmelidir.
Önemli: Ek A kontrollerini gerekçesiz biçimde seçmek, risk değerlendirmesinin ve Uygulanabilirlik Bildirgesi'nin izlenebilirliğini zayıflatır.
Uygulama rehberi
Risk değerlendirmesi
nasıl yapılır?
1. Kapsamı, bağlamı ve kriterleri belirleyin
Bilgi Güvenliği Yönetim Sistemi (BGYS) kapsamı, ilgili süreçler, dış sağlayıcılar, yasal ve sözleşmesel şartlar netleştirilir. Olasılık, etki, kabul sınırı ve artık risk yetkisi herkes için aynı anlama gelecek biçimde tanımlanır.
2. Bilgileri ve bağımlılıkları görünür kılın
Yalnız cihazları değil; kritik süreçleri, müşteri verilerini, SaaS hizmetlerini, tedarikçileri, tesisleri ve kilit rolleri değerlendirin.
3. Neden-olay-sonuç bağlantısıyla risk senaryosu yazın
“Zayıf parola” gibi tek kelimelik ifadeler yerine, olayın hangi nedenle oluşabileceğini ve iş üzerindeki sonucunu açıklayın.
4. Mevcut kontrolleri kanıtlarıyla değerlendirin
Politikanın veya yazılımın varlığı yeterli değildir. Yetki kayıtları, loglar, testler, yedek dönüşleri ve olay kayıtları kontrolün gerçekten çalıştığını göstermelidir.
5. Riski değerlendirin ve sahibini atayın
Risk seviyesi tanımlı kriterlerle karşılaştırılır. Risk sahibi, ilgili süreç ve kaynaklar üzerinde karar yetkisi bulunan kişi olmalıdır; her risk otomatik olarak BT'ye verilmemelidir.
6. İşleme planını ve artık risk kararını yönetin
Azaltma, kaçınma, paylaşma veya kabul seçenekleri gerekçelendirilir. Plan; sorumlu, kaynak, hedef tarih ve etkinlik ölçüsünü içerir.
7. Değişikliklerde yeniden değerlendirin
Yeni teknoloji, tedarikçi, müşteri şartı, önemli olay veya kontrol başarısızlığı risk kaydını ve artık risk kararını tetiklemelidir.
Uygulama rehberi
Ek A ve Uygulanabilirlik Bildirgesi
nasıl bağlanır?
ISO/IEC 27001 Ek A, risk değerlendirmesinden önce otomatik olarak işaretlenecek bir kontrol listesi değildir. Önce gerekli kontroller risk işleme sürecinde belirlenir. Sonra Ek A ile karşılaştırılarak önemli bir kontrolün gözden kaçıp kaçmadığı kontrol edilir. Uygulanabilirlik Bildirgesi, gerekli kontrolleri, uygulanma durumunu ve dahil etme veya hariç tutma gerekçelerini görünür hâle getirir.
Kontrolün Ek A'da bulunması her kuruluşta otomatik olarak uygulanacağı; bulunmaması ise kullanılamayacağı anlamına gelmez. Yasal, sözleşmesel, teknolojik veya kuruluşa özel ek kontroller gerekebilir.
Uygulama örneği
Örnek risk kaydı
| Alan | Örnek içerik |
|---|---|
| Süreç / varlık | Bulut tabanlı müşteri teklif ve sözleşme kayıtları |
| Risk senaryosu | Satış kullanıcısının hesabının ele geçirilmesi sonucu müşteri bilgilerinin dışarı aktarılması |
| Olası nedenler | Kimlik avı, zayıf oturum kontrolü, yetersiz farkındalık |
| Mevcut kontroller | Çok faktörlü kimlik doğrulama (MFA), erişim yetkisi, oturum logları, farkındalık eğitimi |
| Sonuçlar | Gizlilik ihlali, müşteri güven kaybı, sözleşme ve mevzuat etkisi |
| Risk sahibi | Satış süreci sahibi; bilgi teknolojileri (BT) ve bilgi güvenliği desteğiyle |
| İşleme | Koşullu erişim, ayrıcalık gözden geçirme, simülasyon ve olay alarmı |
| Etkinlik kanıtı | MFA kapsamı, test sonuçları, olay ve alarm kayıtları |
Sahada dikkat
En sık yapılan
hatalar
- Envanteri yalnız donanım ve yazılımla sınırlamak.
- Zafiyet taramasını risk değerlendirmesinin tamamı saymak.
- Kontrolü yalnız prosedürde yazdığı için etkili kabul etmek.
- Ek A'yı risklerden önce zorunlu kontrol listesi gibi doldurmak.
- Risk işleme planını sorumlu ve etkinlik ölçüsü olmadan bırakmak.
Uygulama kontrolü
Bilgi güvenliği riski için
uygulama kontrolü
- 01
BGYS kapsamı ve risk kriterleri açık mı?
- 02
Süreç, bilgi, insan, teknoloji ve tedarikçi bağımlılıkları kapsanıyor mu?
- 03
Risk ifadeleri neden-olay-sonuç bağlantısı kuruyor mu?
- 04
Mevcut kontroller kanıtlarıyla değerlendiriliyor mu?
- 05
Risk sahibi ve işleme planı belirli mi?
- 06
Artık riski kabul edecek yetkili açıkça tanımlı mı?
- 07
Uygulanabilirlik Bildirgesi risk kararlarıyla tutarlı mı?
- 08
Değişiklikler ve olaylar yeniden değerlendirmeyi tetikliyor mu?
Bilgi güvenliği risk zinciri
Varlıktan kontrole,
gerekçeli bir karar izi.
Risk kaydı yalnız puan değil; değerlendirmenin hangi olay ve iş etkisinden doğduğunu gösterecek bir karar zinciri sunmalıdır.
Bilgi, süreç, insan, teknoloji ve dış sağlayıcı bağımlılıklarını tanımlayın.
→︎Olayın hangi nedenle ve hangi zayıflıktan yararlanarak oluşabileceğini açıklayın.
→︎Tanımlı kriterlerle iş etkisini ve risk seviyesini değerlendirin.
→︎Kontrolü, sorumluyu, etkinlik ölçüsünü ve kabul yetkisini kayda bağlayın.
Sık sorulan sorular
Merak edilenler
ISO 27001 belirli bir risk matrisi ister mi?＋
Hayır. Kuruluşun tutarlı, tekrarlanabilir ve kendi bağlamına uygun bir yöntem tanımlamasını ister. Nicel, nitel veya karma yöntem kullanılabilir.
Varlık envanteri olmadan risk değerlendirmesi yapılabilir mi?＋
Risklerin kapsamı görebilmesi için ilgili bilgi, süreç ve bağımlılıkların belirlenmesi gerekir. Bunun tek yöntemi ayrıntılı cihaz listesi değildir; süreç ve senaryo temelli yaklaşım da kullanılabilir.
Zafiyet taraması risk değerlendirmesi yerine geçer mi?＋
Hayır. Tarama teknik zayıflıkları gösterebilir; iş sonucu, olasılık, mevcut kontroller, risk sahibi ve işleme kararı ayrıca değerlendirilmelidir.
Bütün Ek A kontrolleri uygulanmalı mıdır?＋
Kontroller kuruluşun riskleri ve ilgili şartları doğrultusunda değerlendirilir. Gerekli kontroller ve gerekçeler Uygulanabilirlik Bildirgesi'nde açıklanır; Ek A eksik kontrol kontrolü için referans setidir.
Birincil kaynaklar
Resmî ve güvenilir
başvuru kaynakları.
ESS Kalite Danışmanlık
YÖNETİM SİSTEMLERİ · EĞİTİM · DENETİM · BELGELENDİRME HAZIRLIĞIESS Kalite Danışmanlık; yönetim sistemleri, eğitim, denetim ve belgelendirme hazırlığı alanlarında kuruluşlara uygulanabilir, güncel ve anlaşılır içerikler sunar.
Bilgi güvenliği risklerinizi süreç ve kanıtlarla eşleştirelim
Kapsam, mevcut durum ve hedeflerinizi kısa bir görüşmeyle netleştirelim.