Anahtar Risk Göstergeleri (KRI) Nasıl Tasarlanır? KPI ile Farkı

Risk kaydı yılda bir güncellenir; risk ise her gün değişir. İki değerlendirme arasında bir zafiyet birikir, MFA’sız hesap sayısı artar, yedek testi aylarca yapılmaz ve risk kaydında hâlâ “orta” yazar. Anahtar risk göstergeleri (KRI) bu boşluğu kapatmak için var: riskin büyüdüğünü, kayıt güncellenmeden önce haber veren ölçülebilir sinyaller. Aşağıda KPI ile KRI’yi ayırıyor, bilgi güvenliği için öncü ve gecikmeli göstergeleri seçiyor ve eşik aşıldığında kimin hangi kararı vereceğini bağlıyoruz.

KPI, KRI ve KCI farkı

Üç kısaltma sürekli karışır, çünkü çoğu zaman aynı veri kaynağından beslenirler. Onları ayıran şey metriğin cevapladığı sorudur.

Gösterge	Cevapladığı soru	Örnek	Tipik sahibi
KPI	Hedefe ulaşıyor muyuz?	Ayda kapatılan güvenlik talebi sayısı	Süreç sahibi
KRI	Risk büyüyor mu?	30 günü aşmış kritik zafiyet sayısı	Risk sahibi
KCI	Kontrol çalışıyor mu?	Zamanında tamamlanan erişim gözden geçirme oranı	Kontrol sahibi

Sahada kullandığımız basit test şu: Gösterge kötüleştiğinde ilk tepki “ekip daha çok çalışsın” ise elinizdeki bir KPI’dır. İlk tepki “maruziyetimiz arttı, kabul ettiğimiz seviyenin dışına mı çıkıyoruz?” ise KRI’dır. KCI ikisinin arasında durur; bir kontrolün işletimde aksadığını erkenden gösterir ve çoğu zaman bir KRI’nin öncüsüdür. Erişim gözden geçirmesi iki çeyrek atlanırsa, birkaç ay sonra yetkisiz erişim KRI’si de kıpırdamaya başlar.

Bilgi güvenliği hedefleri yönetim sisteminin neye ulaşmak istediğini tanımlar; bu tarafı bilgi güvenliği hedeflerinin belirlenmesi rehberinde anlattık. KRI hedeften bağımsızdır. Risk profilinin yönünü izler.

Öncü ve gecikmeli göstergeler

Gecikmeli (lagging) göstergeler olay olduktan sonra sayılır: güvenlik olayı sayısı, veri ihlali bildirimi, plansız kesinti süresi. Gerçek hasarı gösterdikleri için değerlidirler ama geç gelirler. Öncü (leading) göstergeler ise olayın olasılığını artıran koşulları ölçer; hasar oluşmadan önce müdahale payı bırakırlar.

• Gecikmeli: Son çeyrekte kimlik avı kaynaklı ele geçirilen hesap sayısı.
• Öncü: MFA kaydı tamamlanmamış aktif kullanıcı sayısı; kimlik avı simülasyonunda bağlantıya tıklayıp bildirim yapmayan kullanıcı oranı.

Her önemli risk için en az bir öncü gösterge koyun. Yalnız gecikmeli göstergelerden kurulmuş bir pano yönetime geçmişi anlatır, karar için zaman bırakmaz. Gecikmeli göstergeleri de setten atmayın: öncü göstergelerin doğru seçilip seçilmediğini onlar doğrular. Öncü taraf yeşilken gecikmeli taraf kötüleşiyorsa ölçtüğünüz şey yanlıştır. Sahada en sık gördüğümüz tablo da budur.

İyi bir KRI’nin özellikleri

Her aday göstergeyi panoya almadan önce şu listeden geçirin:

• Riske bağlı: Risk kaydında belirli bir satıra referans verir. Bir riske bağlanamayan gösterge, risk göstergesi değildir.
• Ölçülebilir ve tekrarlanabilir: Aynı veri kaynağından, aynı sorguyla, her dönem aynı yöntemle hesaplanır. Hesaplama yöntemi yazılıdır.
• Otomatik toplanabilir: Elle derlenen gösterge ilk yoğun ayda aksar. Veri bir sistem raporundan veya sorgudan gelmeli.
• Eşikli: Yeşil, sarı ve kırmızı bölgeler önceden tanımlıdır ve risk kabul kriterleriyle tutarlıdır.
• Karar tetikleyici: Eşik aşıldığında kimin bilgilendirileceği ve hangi kararın verileceği bellidir.
• Manipülasyona dayanıklı: Sayının iyileşmesi riskin gerçekten azaldığı anlamına gelir. “Açık zafiyet sayısı” tarama kapsamı daraltılarak da iyileşir; bu yüzden taranan varlık sayısını yanına koyun.

Örnek bilgi güvenliği KRI tablosu

Aşağıdaki set orta ölçekli, Microsoft ağırlıklı bir altyapı için hazırlanmış bir örnektir. Eşik değerleri yalnızca örnektir; kendi risk kabul kriterlerinize göre belirleyin.

KRI ve ilgili risk	Veri kaynağı	Örnek eşik (sarı / kırmızı)	Eskalasyon
30 günü aşmış kritik zafiyet sayısı — dış saldırı ile sistem ele geçirme	Zafiyet tarayıcı raporu	>5 / >15	BT müdürü / BGYS komitesi
MFA kaydı olmayan aktif hesap oranı — kimlik bilgisi hırsızlığı	Entra ID kayıt raporu	>%2 / >%5	Kimlik yöneticisi / CISO
90 gündür oturum açmamış etkin hesap sayısı — yetkisiz erişim	Active Directory sorgusu	>10 / >30	Sistem yöneticisi / CISO
Domain Admins üye sayısı — ayrıcalıklı hesap kötüye kullanımı	Active Directory sorgusu	Onaylı listeden +1 / +3	CISO / genel müdür
Son başarılı geri yükleme testinden geçen gün — veri kaybı	Yedekleme test kayıtları	>90 / >180	Altyapı sorumlusu / BGYS komitesi
Süresi geçmiş politika istisnası sayısı — kontrol dışı kalan risk	İstisna kaydı	>0 / >3	Risk sahibi / CISO

Active Directory tarafındaki göstergeler tek bir PowerShell betiğiyle toplanır. ActiveDirectory modülü yüklü bir yönetim sunucusunda:

Import-Module ActiveDirectory

# KRI-03: 90 gündür oturum açmamış, etkin kullanıcı hesapları
$inaktif = Search-ADAccount -AccountInactive -TimeSpan 90.00:00:00 -UsersOnly |
    Where-Object { $_.Enabled }

# KRI-04: Domain Admins grubunun üyeleri (iç içe gruplar açılarak;
# -Recursive yalnız kullanıcı/bilgisayar nesnelerini döndürür, Enabled durumuna bakmaz)
$da = Get-ADGroupMember -Identity "Domain Admins" -Recursive

[pscustomobject]@{
    Tarih        = Get-Date -Format "yyyy-MM-dd"
    InaktifHesap = ($inaktif | Measure-Object).Count
    DomainAdmins = ($da | Measure-Object).Count
} | Export-Csv .\kri_ad.csv -Append -NoTypeInformation -Encoding UTF8

Betiği zamanlanmış görevle aylık çalıştırıp çıktıyı aynı CSV’ye eklediğinizde eğilim grafiği için gereken zaman serisi kendiliğinden birikir. Bir saha notu: Search-ADAccount -AccountInactive değerlendirmesini lastLogonTimestamp özniteliğine dayandırır. Bu öznitelik varsayılan ayarlarda her oturum açılışta değil, 9–14 günlük bir pencereyle güncellenir. 90 günlük eşiği yaklaşık iki haftalık sapmayla okuyun; 14 günün altındaki inaktiflik eşikleri bu yöntemle güvenilir ölçülmez. Zamanlanmış görevin hangi hesapla çalıştığını da kayda geçin. Görev sessizce durursa gösterge de durur.

Eşik ve eskalasyon

Eşik koymanın iki yolu var. Birincisi risk kabul kriterlerinden geriye gitmek: kırmızı eşik, riskin kabul edilemez bölgeye geçtiği noktadır. İkincisi birkaç dönemlik geçmiş veriden başlamak: bugünkü normal seviye sarının hemen altına konur, hedefe göre zamanla sıkılaştırılır. Pratikte ilk dönemde ikincisiyle başlayıp, veri oturdukça birinciye bağlamak daha az sürtünme yaratır. Eşiklerin risk iştahıyla bağı risk kabul kriterleri ve risk iştahı rehberinde ayrıntılı.

Eskalasyon matrisi en az şu üç durumu tanımlamalı:

1. Sarı bölge: Risk sahibi bilgilendirilir, kök neden incelenir ve bir sonraki dönem için düzeltici aksiyon belirlenir. Raporlama rutindir.
2. Kırmızı bölge: CISO veya BGYS komitesi belirlenen süre içinde bilgilendirilir. Risk kaydındaki ilgili satır yeniden değerlendirilir; gerekirse risk işleme planı güncellenir, ek bütçe veya kaynak talep edilir.
3. Ardışık kırmızı: İki dönem üst üste kırmızıda kalan gösterge üst yönetime ayrı karar maddesi olarak taşınır: ya ek kaynak verilir ya da artan risk resmi olarak kabul edilip kayda geçirilir.

Eşik aşımında verilen kararın kaydı, göstergenin kendisi kadar değerlidir. Denetçinin sorusu “gösterge kırmızıya döndüğünde ne yaptınız?” olacaktır. Cevap bir toplantı notu, bir ticket ya da güncellenmiş bir risk satırı olmalı. Sözlü açıklama kanıt değildir.

Gösterge panosu ve raporlama

KRI panosunun yönetim sürümü tek sayfadır. Her satırda gösterge adı, güncel değer, önceki iki dönemin değeri, eğilim yönü, eşik durumu ve bağlı olduğu risk yer alır. Hesaplama yöntemi ve teknik detay ayrı bir ek sayfada durur; yönetim onu okumaz, denetçi okur.

Raporlama ritmini göstergenin değişim hızına göre seçin:

• Aylık: Zafiyet, hesap ve yama göstergeleri; BT yönetimi toplantısında konuşulur.
• Üç aylık: BGYS komitesine eğilim özeti ve eşik aşımlarında alınan kararlar.
• Yıllık: yönetimin gözden geçirmesi girdisi olarak yıl boyu eğilim, gösterge setinin yeterliliği ve eşik revizyonu önerisi.

Panoda yalnız kırmızı satırları göstermek cazip gelir. Yapmayın. Yeşil kalan göstergeler de görünmeli: yönetim riskin nerede kontrol altında olduğunu gördüğünde, kırmızı satırlara istenen kaynağın gerekçesi güçlenir.

Gösterge setinin bakımı

Göstergeler zamanla eskir. Yılda bir her KRI için şu soruları sorun: Bu gösterge geçen yıl herhangi bir karar tetikledi mi? Bağlı olduğu risk hâlâ risk kaydında mı, önceliği değişti mi? Veri kaynağı değişti mi (örneğin şirket içi AD’den bulut kimlik sistemine geçiş)? Hiç eşik aşmayan gösterge ya çok gevşek bir eşiğe sahiptir ya da artık önemli bir riski temsil etmiyordur. Sürekli kırmızıda duran gösterge ise ya gerçekçi olmayan bir eşik taşır ya da yönetimin karar vermediği bir riski işaret eder. İkisi de YGG’de konuşulmalı.

KRI tasarımı genel çerçeve olarak ISO 31000 risk izleme ilkeleriyle uyumludur. Göstergeleri risk kaydıyla birlikte kurup YGG’ye bağlamak için YGG ve KPI tasarımı çalışması, risk kaydının kendisini yeniden ele almak gerekiyorsa bilgi güvenliği risk değerlendirmesi başlangıç noktası olabilir.

Sık sorulan sorular

KRI ile KPI aynı metrik olabilir mi?

Evet. Yama uyum oranı BT ekibi için bir performans hedefidir; aynı oranın belirli bir eşiğin altına düşmesi ise risk sinyalidir. Fark metrikte değil, metriğin hangi soruya cevap verdiğinde ve eşik aşıldığında kimin ne karar vereceğindedir.

Kaç KRI tanımlanmalı?

Sabit bir sayı yok. Yönetime giden setin bir sayfaya sığması ve her göstergenin risk kaydındaki belirli bir riske bağlanması iyi bir ölçüttür. Hiçbir karar tetiklemeyen gösterge setten çıkar.

KRI eşikleri ne zaman güncellenir?

Risk kabul kriterleri değiştiğinde, ilgili kontrol yapısı değiştiğinde veya gösterge uzun süre hiç eşik aşmadan ya da sürekli eşik aşarak bilgi üretmez hale geldiğinde. Bu gözden geçirmeyi en az yılda bir, YGG hazırlığıyla birlikte yapın.

KRI’ler ISO 27001 denetiminde zorunlu mu?

Standart KRI terimini kullanmaz. Ancak madde 9.1 izleme ve ölçme ister; madde 6.1 ve 8.2 risklerin planlı aralıklarla değerlendirilmesini gerektirir. Riske bağlı göstergeler bu gerekliliklerin karşılandığını gösteren güçlü bir kanıttır.