Ancak, mevcut felaket kurtarma (DR) ve iş sürekliliği planlarının fidye yazılımı kurtarma için yeterli olup olmadığı konusunda soru işaretleri var.
Bunu ele almak için I&O Liderleri, mevcut planların potansiyel bir fidye yazılımı saldırısına dayanıp dayanamayacağını daha iyi belirlemek için iki kurtarma yaklaşımı arasındaki beş alanı göz önünde bulundurmalıdır.
- Benzerlikler ve farklılıklar
Geleneksel DR ve fidye yazılımı kurtarmanın, iş sürekliliği yönetimiyle koordinasyon, kurtarma katmanları aracılığıyla önceliklendirme ve bağımlılıkları anlama ihtiyacı dahil olmak üzere birçok benzerliği vardır. Her ikisi de etkiyi değerlendirmek, kurtarma planlarını beyan etmek ve etkinleştirmek, planları yürütmek ve erişim ve bakım konusunda netlik elde etmek için prosedürler gerektirir.
Bununla birlikte, fidye yazılımı kurtarma daha fazla karmaşıklık ve öngörülemezlik içerir ve bu nedenle, doğal olarak farklı paydaşları içerecek olan süreçteki farklı kurtarma adımlarının iş talebini dikkate almak önemlidir. Bunlar arasında çeşitli kurtarma yaklaşımları, konum, veri kaybı, kurtarma süresi ve her zamanki gibi işe dönüş hızı yer alır.
- Olağanüstü Durumdan Kurtarma ‘Tahmin Edilebilir’ Felaketlere Karşı Korur
Geleneksel DR planlaması, tüm konumun veya uygulamanın başarısız olduğunu varsayar ve bir DR konumuna yük devretmeyi gerektirir. Bu olayların kapsamı, bölgesel elektrik kesintilerinden BT ekipmanı arızasına ve hatta tüm altyapıyı yok eden deprem, kasırga ve sel gibi doğal afetlere kadar değişebilir.
Bu olayların planlanması, yük devretmenin makul bir süre içinde ve minimum veri kaybıyla veya sıfır veri kaybıyla gerçekleşmesini sağlayan, veri merkezlerinde etkin veya etkin bekleme uygulama altyapısı gerektirir.
- Felaket Kurtarma Fidye Yazılım Saldırıları için Her Zaman Uygun Değildir
Bugün itibariyle, fidye yazılımı saldırıları, son fidye yazılımı saldırısından haftalar veya aylar önce başlayabilen, çoğunlukla iyi planlanmış durumda. Tipik olarak fidye yazılımları, bu iyi hazırlanmış siber saldırıda yalnızca son adım olarak etkinleştirilir ve saldırganlar saldırı sırasında hâlâ erişime sahiptir.
Geleneksel DR genellikle uygulamaların, verilerin ve birincil site ile DR konumu arasındaki temel ağ hizmetlerinin çoğaltılmasına ve eşitlenmesine dayanır. Bu nedenle, saldırganların üretim sahasının güvenliğini aşmak için yaptığı tüm çalışmalar, DR sitesinde çoğaltılacaktır. DR sitesinin kirlenmesinin, bir siber saldırıdan sonra standart kurtarma prosedürlerini kullanmayı imkansız hale getireceğini düşünün.
En kötü durumda sıfırdan inşa etmek zorunda kalabileceğinizi ve bunun izole kurtarma ortamları, bulut altyapısı, yer değiştirme siteleri ve hizmetleri gibi alternatif altyapılardan kurtarmayı planlamayı gerektireceğini düşünün.
- Felaket Kurtarma ve Fidye Yazılım Kurtarma Farklı Süreçler İzliyor
Geleneksel DR aktivasyonu, felaket olayı tespit edildikten sonra yük devretmenin gerekip gerekmediğine karar vermek için bir değerlendirmenin yürütüldüğü basit bir süreci takip eder. Bundan sonra yük devretme yürütülür ve doğrulanır ve iş devam eder. Birincil ortam kurtarıldığında, iyi planlanmış bir yeniden çalışma (uygun olduğunda) yürütülebilir.
Öte yandan fidye yazılımından kurtarma, çok sayıda ve daha karmaşık aşamalar gerektirir. İlk aşamada, saldırının yürütülmesini ve yayılmasını durdurmaya odaklanılır. İkinci aşamada, ne olduğunu, hangi fidye yazılımının yürütüldüğünü, eldeki güvenlik sorunlarını ve altyapıya nasıl sızdığını bulmak için adli tıp analizi gerekir. Üçüncü aşamada, hangi ağ yapılarının, uygulamaların, verilerin ve yedeklerin etkilendiğini bulmak için analiz yapılması gerekir.
Dördüncü aşamada, ağdaki tüm yapıtların yanı sıra depolama ve bilgi işlem altyapısının geri yüklenmesi veya yeniden oluşturulması ve ardından DNS ve AD gibi ağ hizmetlerinin yeniden oluşturulması veya kurtarılması yoluyla temel altyapının kurtarılmasına odaklanılır. . Beşinci aşamada, birincil ortama geri kurtarmaya hazırlanmak için işletim ve uygulama/veri sistemlerini taramak, onarmak ve doğrulamak için ayrılmış bir izole kurtarma ortamından (IRE) yararlanılır. Son olarak, altıncı aşamada, sistemler IRE’den üretime geri taşınır.
Sistemleri, uygulamaları ve bunların verilerini kurtarabilmeniz için önce altyapı ortamınızdaki etkilenen her öğeyi kurtarmanız ve yeniden korumanız gerektiğinden, tüm altyapı üzerindeki bu etki düzeyi, fidye yazılımı kurtarma işlemini bu kadar karmaşık ve öngörülemez kılan şeydir. Farklı süreçlerle birlikte gelen karmaşıklıkları ve bunun kuruluşunuzdan isteyebileceği talepleri inceleyin.
- Fidye Yazılımını Kurtarmak Bir “Ekip Çabasıdır”
DR genellikle sunucu ekibi, ağ ekibi, depolama ekibi, yedekleme ekibinden oluşan DR ekibi tarafından yönetilir ve bunların tümü DR yöneticisine rapor verir ve daha sonra CIO’ya rapor verir. DR, bir felaket durumunda BT sistemlerinin kurtarılmasından DR’nin sorumlu olduğu daha geniş iş sürekliliği yönetimi sürecinin bir parçasıdır.
Öte yandan, fidye yazılımı kurtarma işlemi, başlangıçta bilgi güvenliği sorumlusuna rapor veren ve Acil Kurtarma ekibi de dahil olmak üzere diğer altyapı ve operasyon ekipleri tarafından desteklenen siber güvenlik olay müdahale ekibi tarafından yönetilir. Bu nedenle, bir fidye yazılımı saldırısından kurtulmak, tüm kurumları kapsayan bir çabadan çok daha fazlasıdır ve buna uygun bir şekilde yaklaşacak kaynaklara sahip olup olmadığınızı düşünün.
Gartner analistleri, 26-28 Eylül tarihlerinde Londra, Birleşik Krallık’ta gerçekleşecek olan gelecek yılki Gartner Güvenlik ve Risk Yönetimi Zirvesi 2023’te felaket kurtarma ve fidye yazılımı kurtarma işlemlerini daha ayrıntılı inceleyecek ve karşılaştıracak.
Jerry Rozeman, Gartner’da Kıdemli Direktör Analistidir