1. GİRİŞ

Modern yazılım ve altyapı ekosistemlerinde güvenlik artık bir kontrol noktası değil, sürekli takip edilen bir süreçtir. Güvenlik metrikleri (security metrics) organizasyonların tehdit ortamını nicel olarak anlamasını, yatırım önceliklerini belirlemesini ve operasyonel kararları veriyle desteklemesini sağlar. Bulut tabanlı dağıtımlar, mikroservis mimarileri ve hızla değişen siber saldırı yöntemleri, belirsizlikleri azaltacak ölçümlere olan ihtiyacı artırdı.

Bu neden bugün konuşuluyor?

• Hızlı dağıtım döngüleri: CI/CD ile sık deploy yapan ekipler güvenlik etkisini ölçmeden hareket edemez.
• Uyumluluk ve regülasyonlar: Denetim için güvenlik göstergelerine ihtiyaç artıyor.
• Olağanüstü olaylar sonrası öğrenme: MTTR/MTTD gibi ölçümler iyileştirilmeyi nicel olarak takip eder.

Kimler için önemli?

Güvenlik liderleri (CISO), SRE/DevOps ekipleri, geliştiriciler, risk yöneticileri ve ürün ekipleri güvenlik metriklerini kullanarak riskleri ve yatırım önceliklerini yönetir. Veri mühendisleri ve observability ekipleri ölçüm altyapısını kurar.

Hangi problemleri çözüyor?

• Güvenlik yatırımlarının etkisini ölçme
• Incident sonrası iyileşme süreçlerinin başarı ölçümü
• Risk bazlı karar alma ve SLA/SLO hedeflerinin güvenlik tarafına uygulanması

2. KAVRAMSAL TEMELLER

2.1 Güvenlik metriği nedir?

Güvenlik metriği, bir güvenlik hedefinin nicel ifadesidir. Nicel hedefler, zaman içinde karşılaştırma, eylem önceliklendirme ve regülatif raporlama sağlar. İyi bir güvenlik metriği ölçülebilir, tekrar üretilebilir, eyleme dönüştürülebilir ve işletme hedefleriyle ilişkilendirilebilir.

2.2 Temel terminoloji

• MTTD (Mean Time To Detect): Bir güvenlik olayını tespit etme ortalaması.
• MTTR (Mean Time To Remediate/Recover): Olayı çözme veya sistemi eski haline getirme süresi.
• Vulnerability density: Kod satırı başına bulunan zafiyet sayısı.
• P0/P1 incident oranı: Kritik seviye olayların toplam olaylara oranı.
• Time to patch: CVE bildirimi ile yamanın üretime uygulanması arasındaki süre.

2.3 Ölçüm mimarisi bileşenleri

Ölçüm mimarisi genellikle şu bileşenlerden oluşur: veri üreticileri (vulnerabilities scanner, EDR, WAF, IDS/IPS, auth logs), veri taşıma (log pipeline, message queues), veri depolama (time‑series DB, OLAP, data lake), analiz katmanı (stream/batch processing, ML modelleri) ve gösterge panoları/alerterlar. Her katmanın güvenilirliği ve geçikmesi metrik doğruluğunu etkiler.

3. NASIL ÇALIŞIR?

3.1 Sistem mimarisi

Güvenlik metriği sistemi, telemetri kaynaklarının standartlaştırılmasıyla başlar. Kaynaklardan gelen olaylar (logs, traces, metrics) normalize edilir, zaman damgası atanır ve birleştirilir. Bu veriler işlenip anlamlı KPI'lara dönüştürülür; örneğin MTTD hesaplanması için tespit timestamp'leri ve olay start timestamp'leri eşleştirilir. Mimari olarak yüksek hacimli veriler için stream processing (Kafka + Flink/Beam) tercih edilirken, karmaşık sorgular için OLAP çözümleri kullanılır.

3.2 Bileşenler ve veri akışı

1. Kaynaklar: EDR, SIEM, vuln scanner, infra metrics (Prometheus), app logs.
2. Ingestion: Fluentd/Vector/Logstash ile toplama ve normalize etme.
3. Pipeline: Kafka gibi mesajlaşma ile güvenilir kuyruklama; stream işleme için Flink/Beam.
4. Storage: TSDB (Prometheus/Influx) ve data warehouse (ClickHouse, BigQuery) kombinasyonu.
5. Analysis & Alerts: Sorgular, anomali tespiti ve ML modelleri ile MTTD, risk skorları hesaplanır.
6. Visualization: Grafana/Looker/Custom dashboards ile SLO/SLA görselleştirme.

3.3 Teknik hesaplama örnekleri

MTTD hesaplamak için olay başlangıç zamanına (t0) ve tespit zamanına (t1) ihtiyaç vardır; sistem bunları tutarlı bir biçimde ilişkilendirebiliyorsa per‑incident MTTD = t1 - t0 formülüyle hesaplanır. Benzer şekilde, Time to Patch için CVE yayın tarihi ve prod deploy tarihleri arasındaki fark toplanıp ortalama alınır. Bu hesapların güvenilir olması için veri kalitesi, senkronizasyon ve timezone yönetimi kritik önemdedir.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Netflix

Netflix, SRE ve güvenlik ekipleri için telemetry ve SLO odaklı yaklaşımlar kullanır. Olayların iş etkisini (customer‑impact) metriklerle bağlamak ve hata bütçesi yaklaşımını güvenliğe uyarlamak (örneğin kritik güvenlik kontrollerinin sağlanmaması durumunda risk alarmı) gerçek dünya pratiğine dönüştürülmüştür.

4.2 Uber

Dağıtık sistemlerde güvenlik telemetrisi yüksek hacimli eventler içerir. Uber gibi firmalar anomali tespiti ve servis bağımlılıklarının güvenlik etkisini ölçerek saldırıların yayılmasını erken tespit etmeye çalışır; ayrıca time to remediate ölçümleriyle müdahale süreçlerini iyileştirirler.

4.3 Amazon (AWS)

Bulut sağlayıcıları müşterilere güvenlik metrikleri sunar (GuardDuty, Inspector). Bu metrikler müşteri ortamının güvenlik sağlık durumunu göstermek ve otomatik remediations tetiklemek için kullanılır. AWS örneğinde, otomatik scanning ve backlog management metrikleri operasyonel kararları destekler.

4.4 OpenAI ve yapay zekâ altyapıları

ML servislerin güvenliğini ölçmek için model inference anomalileri, prompt injection denemeleri ve abuse detection metrikleri gerekir. Bu metrikler model davranış değişimlerini ölçer ve kötüye kullanım senaryolarına karşı erken uyarı sağlar.

4.5 Stripe

Finansal hizmetlerde fraud detection metrikleri, false positive/negative oranları, zamanında tespitin iş değeri ile bağlantısı kritik örnektir. Stripe gibi firmalar model performansını ve güvenlik sonuçlarını birlikte izleyerek risk‑ödül değerlendirmesi yapar.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Objektif değerlendirme: Subjektif yorumları azaltır, yatırım etkisini ölçülebilir kılar.
• İyileştirme döngüsü: Metrikler sayesinde incident sonrası öğrenme ve süreç iyileştirme döngüsü hızlanır.
• Uyumluluk: Denetimler ve regülatif raporlamalar için kanıt sunar.

Sınırlamalar

• Yanıltıcı metrikler: Kötü tasarlanmış metrikler yanlış güven hissi verebilir (Goodhart's law).
• Veri kalitesi: Eksik veya yanlış telemetri ölçümlerin güvenilirliğini bozar.
• Maliyet: Geniş kapsamlı telemetri toplama ve depolama maliyetli olabilir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

Aşağıdaki tablo, farklı güvenlik ölçüm yaklaşımlarını karşılaştırır:

7. EN İYİ PRATİKLER

Production kullanımı

• Hedef odaklı metrikler belirleyin: sadece ölçülebilir değil, eyleme dönüştürülebilir metrikler seçin.
• SLO belirleme: güvenlik SLO'ları (ör. kritik açıkların 72 saat içinde patchlenme oranı) tanımlayın.
• Ownership: her metriğin bir sahibi olsun (takım veya rol) ve düzenli review süreçleri yapılsın.

Performans optimizasyonu

• Sampling stratejileri ile veri maliyetlerini dengeleyin; kritik olaylarda full‑trace toplayın.
• Aggregation ve downsampling politikaları uygulayın; kısa dönem yüksek çözünürlük, uzun dönem özet veriler saklayın.

Güvenlik

• Telemetri verilerini şifreleyin ve erişimi kısıtlayın; log tamper‑proofing için write‑once storage veya WORM politikaları düşünün.
• Alert fatigue'i önlemek için alerting kurallarını dikkatle tasarlayın; kritik olaylar için eskalasyon playbook'ları tanımlayın.

Ölçeklenebilirlik

• Stream processing ve event‑driven mimari ile yüksek hacimli telemetriyi gerçek zamanlı işleyin.
• Storage tiering ile maliyet/performans optimizasyonu sağlayın.

8. SIK YAPILAN HATALAR

• İzlenebilirlik eksikliği: metrikleri kurmadan önce veri kaynaklarını envantere almamak.
• Yanlış motivasyon: Metriklerin sadece 'iyi görünmek' için seçilmesi (vanity metrics).
• Teknik borç: Metrik hesaplama mantıklarını kodda düzgün dokümante etmemek.
• Aksiyon eksikliği: Metriğin ölçülmesi ile eylem planı bağının kurulmamış olması.

9. GELECEK TRENDLER

9.1 AI ve otomatik güvenlik operasyonları

Yapay zekâ destekli analitikler anomali tespiti ve önceliklendirmede daha etkili olacak; otomatik playbook'lar ile MTTR kısalacak. Ancak bu sistemler de yanlış pozitifleri azaltmak için insan‑in‑the‑loop gerektirecek.

9.2 Standardizasyon ve semantik metrikler

Güvenlik metrikleri için endüstri standartlarının (ör. OpenTelemetry genişletmeleri) yaygınlaşması, metriklerin kıyaslanabilirliğini artıracak ve benchmarking imkânı sağlayacak.

9.3 Metriklerin finansal etkiye bağlanması

Güvenlik metrikleri daha sık şekilde finansal metriklerle ilişkilendirilecek: saldırıların iş kaybına etkisi, yama gecikmelerinin maliyeti gibi göstergeler yatırım kararlarını doğrudan etkileyecek.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. Hangi güvenlik metrikleri önceliklidir?

   Öncelik iş bağlamına göre değişir; genelde MTTD, MTTR, time to patch, vuln remediation rate ve critical incident oranları başlangıç için iyi metriklerdir.

2. Metrikler manipüle edilebilir mi?

   Evet; bu yüzden metrikleri tasarlarken oyunlaştırma riskini (Goodhart's law) göz önünde bulundurun ve metrik sahipliği ile denetimler kurun.

3. Kaç metrik idealidir?

   Az ama öz: 5–10 ana KPI genelde yeterlidir; alt metriklerle detaylandırma yapılır.

4. Metrikleri nasıl görselleştirmeliyim?

   Trend grafikleri, burn‑down chart'lar, heatmap'ler ve top‑N listeler kullanın; olay bağlamında zaman çizelgesi (timeline) kritik olay incelemeleri için faydalıdır.

5. Telemetry maliyetlerini nasıl kontrol ederim?

   Sampling, aggregation, retention policy ve cold storage tiering ile maliyetleri yönetin.

6. Güvenlik SLO'su nasıl tanımlanır?

   Örneğin: "Kritik açıklara karşı patch uygulama süresinin %95'i 72 saat içinde tamamlanır" gibi ölçülebilir hedefler belirleyin.

7. ML/AI metrikleri güvenlik izlemede nasıl kullanılır?

   Anomali tespiti, davranışsal modelleme ve risk scoring için ML kullanılabilir; modellerin doğruluğunu ve drift'ini izlemek de ayrı metriktir.

8. Regülatif raporlama için hangi metrikler uygundur?

   İlgili regülasyonun gerektirdiği şeffaflığı sağlayan, izlenebilir ve doğrulanabilir metrikler seçilmelidir (ör. incident count, time to notify).

Anahtar Kavramlar

MTTD

Bir güvenlik olayını tespit etme ortalaması.

MTTR

Bir olayı çözme veya sistemi eski haline getirme ortalaması.

Vulnerability density

Belirli bir kod veya bileşen başına düşen zafiyet sayısı.

SLO

Servis Seviyesi Hedefi — güvenlik için tanımlanmış ölçülebilir hedef.

Telemetry

Sistemlerden toplanan ölçümler, loglar ve izler bütünü.

Öğrenme Yol Haritası

1. 0–1 ay: Temel güvenlik kavramları, SIEM, temel logging ve monitoring araçlarını öğrenin.
2. 1–3 ay: Prometheus, Grafana, ELK stack gibi telemetri araçları ile pratik yapın; basit MTTD/MTTR hesaplamaları kurun.
3. 3–6 ay: Stream processing (Kafka/Flink), OLAP ve data warehouse temelleri; güvenlik metriklerini üretim ortamına taşıyın.
4. 6–12 ay: Anomali tespiti için ML modelleri, SLO bağlamlı güvenlik ve düzenli incident post‑mortem süreçleri kurun.
5. 12+ ay: Güvenlik metriklerini finansal etkiyle bağlama, regülasyon uyumluluğu ve sektör kıyaslama (benchmarking) üzerinde uzmanlaşın.