Kritik Açık Çıktı, Hemen Upgrade Etmeniz Gerekiyor. Peki Ya Fix Başka Bir Şeyi Bozarsa? | BackBox #03

Yeni bir kritik güvenlik açığı yayınlandı. Kullandığınız network veya security ürününün etkilendiği doğrulandı. Vendor fix'i yayınladı. Security ekibi beklemek istemiyor. Yönetim riskin ne zaman kapatılacağını soruyor.

Upgrade etmeniz gerekiyor. Hem de hızlı.

Ama network operasyonlarında hepimizin bildiği başka bir gerçek var:

Bir güvenlik problemini çözen fix, hiç beklemediğiniz başka bir problemi ortaya çıkarabilir.

Şimdi iki risk arasında karar vermeniz gerekiyor. Upgrade'i geciktirip bilinen vulnerability ile yaşamaya devam etmek. Ya da hızla upgrade edip production üzerinde yeni bir operasyonel risk almak.

Peki üçüncü bir seçenek mümkün mü?

Hızlı upgrade edip, bir şey ters giderse hızlı geri dönebilmek.

Artık "Bir Sonraki Maintenance Window'u Bekleyelim" Demek Her Zaman Mümkün Değil

Network ve security ürünlerindeki vulnerability'ler yeni değil. Değişen şey hız. Kritik açıklar çok hızlı duyuluyor. PoC'ler yayınlanabiliyor. Exploit girişimleri başlayabiliyor. Security ekipleri remediation sürelerini kısaltıyor.

Ve özellikle internet-facing firewall, VPN gateway, router veya diğer kritik cihazlarda haftalarca beklemek kabul edilebilir olmayabiliyor.

Bu da network ekiplerinin üzerindeki baskıyı artırıyor.

Daha hızlı patch. Daha hızlı upgrade. Daha kısa exposure window.

Bunların hepsi doğru hedefler. Ancak hız arttıkça operasyonel güvence daha önemli hale geliyor. Çünkü production ortamında yapılan her upgrade'in bir başka tarafı daha var.

"Vendor Recommended" Risksiz Demek Değildir

Vendor'ın önerdiği bir software release kullanıyor olabilirsiniz. Release note'ları okumuş olabilirsiniz. Known issue'ları kontrol etmiş olabilirsiniz. Lab testlerini tamamlamış olabilirsiniz. Bunların hepsini yapmanız gerekir. Ama production ortamınız lab ortamınız değildir. Gerçek trafik vardır. Routing vardır. VPN'ler vardır. Cluster davranışları vardır. Authentication entegrasyonları vardır. Inspection özellikleri vardır. API bağlantıları vardır. Üçüncü parti sistemlerle entegrasyonlar vardır.

Yıllar içerisinde oluşmuş, bazen dokümantasyonda bile görünmeyen bağımlılıklar vardır.

Ve bazen upgrade başarılı tamamlanır. Cihaz ayağa kalkar. Dashboard yeşildir. Ama birkaç dakika sonra telefon çalar.

Bir şey çalışmıyor.

Upgrade Başarılı. Servis Başarısız.

İşte en tehlikeli senaryolardan biri budur. Teknik olarak upgrade tamamlanmıştır. Cihaz erişilebilir durumdadır. Cluster üyeleri up görünmektedir. Temel kontroller başarılıdır. Ama kritik bir uygulamanın trafiği geçmiyordur. VPN kullanıcılarının bir bölümü bağlanamıyordur. Routing beklediğiniz gibi davranmıyordur. Bir integration kırılmıştır. Ya da belirli bir security fonksiyonu farklı davranmaya başlamıştır. Yani:

Upgrade job'ının "Success" olması, operasyonun başarılı olduğu anlamına gelmez.

Tıpkı backup'ta olduğu gibi. Bu noktada artık soru şudur:

Ne kadar hızlı geri dönebilirsiniz?

Rollback Planınız Bir Doküman mı, Gerçek Bir Operasyon mu?

Çoğu değişiklik planında bir rollback bölümü vardır. "Problem durumunda önceki versiyona dönülecektir." Kağıt üzerinde güzel. Peki gerçekten? Upgrade öncesindeki son configuration nerede? Doğru backup alındı mı? Kullanılabilir olduğu doğrulandı mı? Hangi software image gerekiyor? Cihazın eski version'a dönüş prosedürü ne? Configuration compatibility nasıl yönetilecek? Cluster varsa hangi sırayla işlem yapılacak? Geri dönüş sonrasında hangi kontroller gerçekleştirilecek? Ve en önemlisi:

Bütün bunlar kaç dakika sürecek?

Çünkü production kesintisi başladığında rollback planınızın ne kadar güzel yazıldığı değil,

ne kadar hızlı uygulanabildiği önemlidir.

Asıl Sigorta Upgrade'den Önce Başlar

Güvenli bir upgrade operasyonunun en kritik bölümlerinden biri aslında upgrade başlamadan önce gerçekleşir.

Mevcut durumun bilinmesi. Doğru configuration'ın alınması. Recovery point'in oluşturulması. Pre-check'lerin tamamlanması. Gerekli image ve kaynakların doğrulanması. İşlem adımlarının standartlaştırılması. Upgrade sonrasında yapılacak kontrollerin belirlenmesi. Ve gerektiğinde geri dönüş yolunun hazır olması. Böylece teknik ekip:

"Umarım problem çıkmaz."

yaklaşımıyla değil,

"Problem çıkarsa ne yapacağımız hazır."

güveniyle değişiklik yapabilir. İkisi arasında çok büyük bir operasyonel fark vardır.

BackBox Burada Neyi Değiştiriyor?

BackBox'ın değerini yalnızca "upgrade otomasyonu" olarak tanımlamak eksik kalır. Çünkü amaç sadece yüzlerce cihaz üzerinde upgrade komutlarını otomatik çalıştırmak değildir.

Asıl değer upgrade lifecycle'ının standardize edilmesidir. Pre-check. Configuration backup. Recovery point. Software upgrade. Post-check. Ve gerektiğinde rollback.

Bu adımların tekrar edilebilir bir operasyon haline gelmesi, özellikle farklı vendor ve cihazların bulunduğu büyük ortamlarda ciddi bir fark yaratır.

Bir mühendisin gece saatlerinde manuel olarak onlarca adımı takip etmesi yerine süreçlerin önceden tanımlanmış ve tekrarlanabilir olması yalnızca zaman kazandırmaz.

İnsan hatası riskini de azaltır.

10 Cihazda Manuel Upgrade Başka, 300 Cihazda Başka Bir Problemdir

Bir firewall'ı manuel upgrade etmek yönetilebilir olabilir. Beş cihaz da olabilir.

Ama yüzlerce network ve security cihazının bulunduğu yapılarda kritik bir vulnerability ortaya çıktığında ölçek tamamen değişir.

Hangi cihaz etkileniyor? Hangi version çalışıyor? Hangisi önce upgrade edilmeli? Hangi image kullanılacak? Backup'ı hazır mı? Upgrade başarılı oldu mu? Post-check sonucu ne? Problem yaşayan cihaz var mı? Rollback gereken cihaz hangisi?

Bu sorular yüzlerce cihaz için sorulmaya başladığında artık konu yalnızca teknik bilgi değildir.

Operasyonel ölçek problemidir.

Ve otomasyonun gerçek değeri burada ortaya çıkar.

Patch Etmemek Risk. Patch Etmek de Risk.

Network güvenliğinde bazen sıfır riskli seçenek yoktur. Bilinen vulnerability ile beklemek risklidir. Hızlı upgrade yapmak operasyonel risk taşır. Bu nedenle hedef riski tamamen ortadan kaldırmak değil,

riski kontrol edilebilir hale getirmektir.

Bunun en güçlü yollarından biri de geri dönüş süresini mümkün olduğunca kısaltmaktır. Çünkü bir upgrade'in beklenmeyen etkisini tamamen öngöremeyebilirsiniz. Ama o etki ortaya çıktığında ne yapacağınızı önceden belirleyebilirsiniz.

90 Dakikalık Kesinti mi, 10 Dakikalık Rollback mi?

Burada teknoloji doğrudan maliyete dönüşmeye başlar. Kritik bir network veya security cihazında upgrade sonrasında problem çıktığını düşünün.

Teknik ekip teşhis yapıyor. Eski configuration aranıyor. Doğru image kontrol ediliyor. Rollback prosedürü inceleniyor. İşlem manuel başlatılıyor. Servis kontrolleri yapılıyor. Bu süreç uzadıkça kesintinin maliyeti büyüyor.

Şimdi aynı senaryoda upgrade öncesindeki recovery point'in hazır olduğunu ve geri dönüş operasyonunun standardize edildiğini düşünün.

Kazandığınız şey yalnızca mühendislik zamanı değildir.

Downtime'ı satın alıyorsunuz. Ya da daha doğrusu,

downtime'ın süresini azaltıyorsunuz.

İşte BackBox'ın kendisini çok hızlı amorti edebildiği noktalardan biri tam olarak burasıdır.

Bir Sonraki Kritik CVE'de Kendinize Şunları Sorun

Hangi cihazlarımız gerçekten etkileniyor?

Bunların tamamını ne kadar sürede upgrade edebiliriz?

Upgrade öncesinde doğru recovery point'i otomatik oluşturabiliyor muyuz?

Upgrade sonrasında yalnızca cihazın değil, operasyonun sağlıklı olduğunu doğrulayabiliyor muyuz?

Ve en önemlisi:

Bir şey ters giderse kaç dakika içerisinde geri dönebiliriz?

Son sorunun cevabını bilmiyorsanız, upgrade planınızın önemli bir parçası eksik olabilir.

Zero Second olarak BackBox ile network ve security altyapınızdaki upgrade, backup ve recovery operasyonlarını birlikte değerlendirebilir; özellikle kritik vulnerability senaryolarında patch'ten rollback'e kadar geçen sürecin ne kadar hazır olduğunu ortaya çıkarabiliriz.

Çünkü günümüzde mesele yalnızca vulnerability'yi ne kadar hızlı kapattığınız değil.

Bir şey ters gittiğinde ne kadar hızlı geri dönebildiğinizdir.

Patch Etmemek Risk. Patch Etmek de Risk. Peki Rollback'iniz Hazır mı?

Zero Second | BackBox — Network Cyber Resilience | BackBox Series #03 — Prepared by Zero Second