Operasyon Runbook’u (Incident Flow, Playbook, KPI Ölçümleri)
Bir güvenlik çözümünün kurum içinde etkin şekilde kullanılması, iyi tanımlanmış operasyonel süreçlere bağlıdır. Bu bölümde, Acronis Advanced Security + EDR ile yürütülecek bir güvenlik olay yönetimi akışını (incident flow) ve bunun adımları için bir playbook taslağını sunacağız. Ayrıca, güvenlik operasyonlarının başarısını değerlendirmek için önemli KPI (Key Performance Indicator) metriklerine değineceğiz.
Incident Response Akışı (Flow)
Acronis EDR’yi kullanarak bir olay müdahalesi genel olarak şu adımları takip edecektir (NIST SP 800-61 ve ISO 27035 gibi standartlardan da referansla):
- Hazırlık (Preparation): Olay gerçekleşmeden önce yapılması gerekenler. Bu, runbook’un belki de en önemli ama sessiz kısmıdır. Acronis platformu kurulu ve düzgün çalışıyor olmalı, personel kullanıma dair eğitimli olmalı, iletişim planları hazır olmalı. Hazırlık aşamasında:
- Politikalar ve otomasyonlar tanımlanır (örneğin kritik olay olursa yönetime haber ver, vs.).
- İlgili çalışanların iletişim bilgileri ve roller listelenir (Saat 03:00’de kritik alarm gelirse kim nöbette olacak?).
- Yedekleme/rollback testleri periyodik yapılır (bu da hazırlığın bir parçası).
- Olay müdahale ekipmanları (yönetim laptopu, vs.) hazır bulundurulur.
- KPI: Hazırlık aşaması için ölçülebilecek bir KPI, “Olay Müdahale Planı güncelliği” veya “Yılda x kez tatbikat yapıldı mı” olabilir. Bu, Acronis aracı ile doğrudan ölçülmez ama genel bir güvenlik KPI’ıdır.
- Tespit ve Tanımlama (Detection & Identification): Bir olayın Acronis EDR tarafından algılanıp incident olarak tanımlandığı aşama. Bu, runbook akışının başlayacağı tetikleyicidir.
- Acronis konsolu bir alarm/incident üretir (ör. “CryptoLocker behavior detected on PC-123”).
- Bu alarm belki entegre sistemler aracılığıyla SOC ekibine iletilir (SIEM, email, vs.).
- İlk değerlendirme: Görevli analist alarma bakar, bunun gerçek bir tehdit olup olmadığını anlamaya çalışır (triage adımı). Acronis burada yardımcı özet ve MITRE eşleştirmesini sunar.
- Eğer alarm false positive ise (yanlış pozitif), olay kapatılır, gerekirse ilgili kural iyileştirilir (ör. meşru uygulamayı allowlist’e ekle). False positive KPI olarak takip edilir.
- Eğer alarm gerçek ise, olay “tanımlandı” kabul edilip müdahale moduna geçilir. Bu noktada olay bir kayıt numarası alır (ticket açılır ya da olay formu doldurulur).
- KPI: “Mean Time to Detect (MTTD)” – bir tehdidin ortamda oluşmasından tespit edilmesine kadar geçen süre. Acronis EDR çoğu şeyi gerçek zamanlı yakaladığı için MTTD saniyeler mertebesinde olabilir. Ancak bu KPI’e genellikle manuel onay süresi de dahil edilir: Alarm oluştu – analist gördü/geç fark etti = bu da tespit süresine eklenir. Acronis entegre uyarılar bunu düşürmeyi hedefler. Amaç MTTD’yi olabildiğince düşürmek (<5 dk gibi).
- İçerme (Containment): Olay teyit edilir edilmez, öncelikle tehdidin yayılımını önleme adımları atılır.
- Acronis konsolundan ilgili uç nokta hemen izole edilir (network isolation).
- Zararlı süreç hala çalışıyorsa kill process yapılır.
- Mümkünse cihaz kapatılmaz ama gerekirse power-off da bir containment yöntemidir (ancak bu rollback’i zorlaştırır, ondan kaçınmak isteriz).
- Containment adımı, hızlı ve otomatik olmalıdır. Acronis bazı olaylar için otomatik containment yapabilir (policy ile “auto-isolate on ransomware” gibi).
- KPI: “Mean Time to Contain” – olay tespit edildikten cihaz izole edilene kadar geçen süre. İyi bir EDR kullanımı ile bu dakikalar içinde olur. Örneğin <15 dk gibi. Bu değeri runbook sonrasında raporlarda izlemek önemli, yüksek ise süreci iyileştirmek gerekir.
- Containment sonrası takım toplanır (sanal olarak belki chat kanalında) ve sonraki adımı planlar.
- Eradikasyon (Eradication): Tehdidin sistemden tamamen kaldırılması safhası.
- Acronis ile bu adım entegre: Quarantine ile zararlı dosyalar temizlenir, rollback ile yaptıkları değişiklikler silinir.
- Örneğin bir trojan enfeksiyonuysa, EDR’nin raporladığı IoC’ler (dosya hash’leri, kalıcılık kayıtları) rehberliğinde sistemde arama yapılır, varsa manuel de temizlenir.
- Forensic backup alınmamışsa bu aşamada bir imaj alınabilir (delil için).
- Acronis ile patching de eradication parçası olabilir: Saldırgan bir zafiyetten girdiyse yama hemen uygulanır.
- KPI: “Threat Eradication Success Rate” – belki nicel ölçmesi zor, ama mesela “% of incidents fully remediated without escalation” gibi bir KPI konabilir. Acronis çözemezse belki farklı araç gerekebilir, ama idealde tüm vakalar Acronis ile halloluyor mu bakılır.
- Bu aşamada, eğer ağır bir etki varsa (çok sayıda makine etkilendiyse), BCP/DR planları devreye girer. Acronis’in rollback’i çalışmaz veya uzun sürerse, belki yedekten restore edilir vs. Runbook bu alternatifleri de içermeli.
- Kurtarma (Recovery): Sistemlerin normal operasyonlarına geri döndürülmesi.
- Isolation alınan makineler, temizlendikten sonra network’e geri dahil edilir. Bu kararı verip izolasyonu kaldırmak runbook’ta onay gerektirebilir (ör. SOC manager onayı).
- Kullanıcıya şifresini değiştirmesi gibi aksiyonlar iletilebilir (eğer credential theft olduysa).
- Rapid Rollback yapıldıysa, kullanıcılara ilgili dosyaları kontrol etmeleri istenir.
- Eğer makine tamamen yeniden kurulmuşsa (worst-case), yedekten dönülür ve kullanıcı işine devam eder.
- Bu aşamada, iş birimlerinin operasyonları tekrar sorunsuz sürdürdüğü doğrulanır. Yani “iş kesintisi sona erdi” anı burada biter.
- KPI: “Mean Time to Recover (MTTR)” – Burada R harfi “Recover” ya da “Respond” anlamında kullanılabiliyor sektöre göre. Özetle olay başlangıcından işler normale dönene kadar geçen toplam süre diyebiliriz. Acronis platformu iddia ediyor ki entegre yaklaşımla MTTR’yi dramatik şekilde düşürür. Bu PoC sırasında da belki gözlenmiştir. Bu KPI olabildiğince düşük olmalı (< 1 gün ideal, kritik bir ransomware mesela günler sürebilir ama Acronis ile belki saatlere inebilir).
- Recovery sırasında Acronis, etkilenen sistemlerin backup sürekliliğini de kontrol eder (yeni yedek al, emin ol her şey güvende vs.).
- Lessons Learned (İyileştirme ve Değerlendirme): Her ciddi olaydan sonra bir post-incident review yapılması, runbook’un son ama çok önemli adımıdır.
- Ekip toplanıp ne oldu, nasıl oldu, neler iyi gitti/kötü gitti değerlendirir. Acronis raporları burada kullanılır; olayın tam timeline’ı, MITRE adımları, nelerin kaçırıldığı vs. incelenir.
- Kök neden analizi: Saldırı nasıl girdi? Örneğin phishing ile mi? O zaman belki kullanıcı eğitimi eksik, e-posta filtresinde kural eksik. Veya bir RDP açıktı, zafiyetten girdiler – demek ki zafiyet yönetimi geliştirilmeli.
- Acronis EDR’de bu saldırıya dair kural güncellemek gerekirse yapılır (mesela IoC blocklist’e eklenir).
- Varsa hukuki/uygulama gereği raporlama (KVKK bildirim, sigorta bildirimi vs.) bu adımda halledilir.
- KPI: “Incident Closure Time” – olayın tamamen kapatılıp raporunun çıkması ne kadar sürdü. Ve “Number of repeat incidents” – benzer olay tekrar yaşandı mı? Lessons learned etkin ise tekrar etmemelidir. Bu daha uzun vadeli bir KPI.
- Bu aşamada runbook’un kendisi de güncellenebilir. Örneğin bu olayda runbook’ta eksik bir adım fark edildi, eklenir.
Runbook’un Uygulanması: Yukarıdaki akış, pratikte bir playbook dokümanı olarak yazılmalıdır. Hatta Acronis EDR, 2024 ortalarında otomatik playbook özelliği duyurmuştur (XDR kapsamında). Bu, belirli olaylarda otomatik aksiyon dizileri tanımlamayı sağlar. Örneğin “Eğer ransomware tespit edilirse: 1) PC’yi izole et, 2) yedek al, 3) rollback yap, 4) ticket aç” gibi bir otomasyon kurulabilir. Bu, runbook’taki adımların bazısını otomatikleştirebilir. Ancak tam otomasyon her zaman riskli olabileceğinden (yanlış alarmda gereksiz aksiyon olabilir), genelde yarı otomatik tercih edilir (öneri sunulur, analist onaylar).
Acronis ile entegrasyona gidilmiş bir SOC’da, runbook belki SOAR platformuna da kodlanabilir. Örneğin D3 Security ile entegre ise, Acronis alarmını alıp yukarıdaki adımları bir playbook içinde yürütüp, analiste yönlendirmeler yapan bir arayüz olabilir. Bu gelişmiş seviye, otomatize incident response demektir.
Önemli KPI’ların İzlenmesi
Güvenlik operasyon merkezleri, faaliyetlerinin etkinliğini göstermek için KPI’lar tanımlar. Acronis EDR kullanımı için öne çıkan KPI’lar şunlardır:
- MTTD (Mean Time to Detect): Tehdidin ortamda belirmesinden Acronis’in alarm üretmesine kadar süre. İdeal olarak birkaç dakika içinde olmalıdır. Acronis real-time çalıştığı için sıfıra yakın olabilir, ancak insan faktörü eklenince (analist görme zamanı) biraz artar.
- MTTR (Mean Time to Respond/Recover): Olayın tespitinden tamamen çözümlenip kapanmasına kadar geçen ortalama süre. Bu, belki en kritik KPI. Acronis entegre rollback ile bu süreyi günlerden saatlere indirir iddiasında. Bu PoC’de ölçüldü ise kurum hedef koyabilir: Örneğin “kritik bir ransomware olayı olursa, 4 saat içinde sistemler geri dönmüş olacak” gibi.
- Incident Count by Severity: Belirli periyotta (aylık) kaç adet düşük, orta, yüksek seviye olay yaşandı. Acronis’in konsolu bu veriyi raporlar. Burada amaç güvenlik posture trendini izlemektir. Olay sayısı anormal artıyorsa belki yeni saldırı dalgası var demektir.
- False Positive Rate: Yanlış alarm yüzdesi. Örneğin Acronis 100 alarm üretti, bunun 5’i yanlıştı = %5 F/P. Bu oranın düşük olması istenir (<%10 gibi). Yüksekse, ya kural iyileştirme ya başka tuning gerekir, yoksa analistlerin vakti boşa gider.
- Auto-block Success: Acronis otomatik olarak kaç tehdidi durdurmuş? Örneğin 10 fidye girişimi oldu, 9’u kullanıcı fark etmeden engellendi, 1’i kısmen başarılı oldu (dosya şifrelendi) ama rollback yaptık. Bu da bir başarı metriğidir. Yine belki “%98 malware blocked automatically” gibi rapor edilebilir.
- Remediation Rate: Tespit edilen olayların yüzde kaçı tamamen giderildi? (100 olay oldu, 100’ü de temizlendi – ideal). Bazı olaylar temizlenemedi ise (örn. bir cihaz format atmak gerekti belki), bu da not edilir.
- Downtime / Business Impact: Olayların iş kesintisine etkisi dakika/saatsel ölçülebilir. Örneğin kritik sunucu 2 saat offline kaldı. Acronis ile belki bu 0 saat oldu (çünkü failover yaptı). Bu da operasyonel bir KPI.
- Compliance Metrics: Belki NIST CSF skor kartı (Acronis bunu dolaylı sağlayabilir, belki dashboard’unda bir NIST coverage grafiği var?), veya denetimlerde sorulan “log’lar tutuluyor mu, olay kaydı var mı” gibi maddeler Acronis ile check edilebilir. Bu daha denetim KPI’sı ama başarı sayılabilir.
- Kullanıcı Memnuniyeti: Son kullanıcı açısından bir KPI: “Security Operations memnuniyet anket skoru” vs. EDR kullanımı buraya etki eder. Örneğin kullanıcılar memnun ki bir saldırı olursa hızla çözülüyor, veri kaybı yok. Veya memnuniyetsiz olabilirler çünkü belki EDR bazen uygulamalarını blokluyor. Bu subjektif ama önemli bir geri bildirim kaynağıdır.
KPI’lar düzenli aralıklarla (aylık, çeyreklik) raporlanmalı ve hedefler konulmalıdır. Mesela hedef: MTTR < 4 saat, False positive < %5, Critical incidents per quarter < 2 vs. Bu hedefler zamanla sıkılaştırılır.
Acronis konsolu bazı raporlamaları otomatik yapar; örneğin haftalık özet raporunda kaç olay, kaç engellenen tehdit vs. var gösterir. Bu raporlar KPI takibinde kullanılabilir veya daha ileri analiz için dışa aktarılıp Excel’de/power BI’da işlenebilir.
Runbook Bakımı: Bu operasyon runbook’u yaşayan bir dokümandır. Yeni tehdit türleri çıktıkça veya Acronis platformuna yeni özellik geldikçe güncellenmelidir. Örneğin Acronis bir gün IoC auto-block özelliği getirirse (belki var zaten), runbook’a “Indicator found in threat feed -> auto-block in policy” gibi adımlar eklenebilir. Ya da Acronis XDR’ye geçildiğinde network ve cloud olayları da bu akışa entegre edilebilir.
Sonuç: İyi tanımlanmış bir runbook, olay anında stresi azaltır ve her ekibin ne yapacağını bilmesini sağlar. Yukarıdaki şablon, Acronis EDR’yi kullanarak bir olayın uçtan uca ele alınışını açıklamaktadır. Özellikle Rapid Rollback ve entegre yanıt gibi Acronis’e özgü adımlar, klasik runbook’lardan farklılıklar içeriyor (ör. normalde ayrı bir backup ekibi çağırmak gerekebilirdi, Acronis ile SOC ekibi kendisi rollback yapabiliyor). Bu, runbook’ta rol dağılımını da etkileyebilir (SOC ekibi belki eskiden sadece tespitle uğraşırdı, şimdi kurtarma aksiyonunu da onlar alabiliyor, bu iyi bir şey fakat ek sorumluluk). Bu yüzden runbook’u kurumun yapısına göre adapte etmek önemli.
Bu bölümle birlikte, teknik operasyon kısmını da tamamlamış olduk. Bir sonraki kısımda, Acronis Advanced Security + EDR kullanımıyla ilgili çeşitli risk senaryoları ve edge-case durumları üzerinde duracağız – çözümün sınırları, olası problem durumları ve bunlara karşı alınabilecek önlemleri tartışacağız.
