Fidye yazılımından önce yapmanız gereken yedek geri yükleme testi

Fidye yazılımı yedeklerinizi sınamadan önce üç kontrolü kendiniz yapın: yedekleri herhangi birinin silip silemeyeceği, çalınmış bir yönetici hesabının onlara ulaşıp ulaşamayacağı ve gerçek bir geri yüklemenin iş biriminin tolere edebildiği süreye kıyasla ne kadar sürdüğü.

NCSC'nin kötü amaçlı yazılım ve fidye yazılımı saldırılarının azaltılmasına dair rehberi çok açık konuşuyor. Güncel yedekler, bir fidye yazılımı saldırısından kurtulmanın en etkili yoludur. Fidye yazılımı ödeme ihtimalini artırmak için yedekleri bilinçli olarak hedef alır ve saldırganlar, saldırıyı başlatmadan önce kopyalanmış dosyaları yok etmiş ya da kurtarma sürecini aksatmıştır. Dolayısıyla yedekleri tıpkı bir saldırganın yapacağı gibi test edin.

Test 1: Kendi yedeğinizi silmeyi deneyin

Buradaki örneklerde Amazon S3 Object Lock kullanılıyor. Başka bir ortamda çalışıyorsanız, yedekleme ürününüzdeki eşdeğer değiştirilemezlik (immutability) ya da saklama kilidi özelliğini bulun. Özelliğin açık olduğunu, saklama süresinin ne kadar olduğunu ve bu süreyi kimin kısaltabileceğini ya da kaldırabileceğini kontrol edin. Ardından kalıcı silme işlemini sırasıyla sıradan bir kullanıcı olarak, en yetkili yedekleme yöneticiniz olarak ve bir saldırganın ele geçirmesi makul olan bir hesap olarak deneyin. Kimin başarılı olduğunu kaydedin.

S3 için bir deneme bucket'ında çalışın. Object Lock yalnızca S3 Versioning'in etkin olduğu bucket'larda çalışır, bu yüzden önce bunu kontrol edin. AWS'nin, compliance mode saklama süresi oluşturmadan önce saklama ayarlarını test etmenin bir yolu olarak tanımladığı governance mode'u kullanın.

Deneme bucket'ında asla compliance mode uygulamayın. Compliance mode'da saklama modu değiştirilemez ve süre kısaltılamaz. Compliance kilidi bulunan bir nesneyi erkenden silmenin tek yolu, ilişkili AWS hesabını silmektir.

Bu denemeleri hem konsol üzerinden hem de API ya da CLI ile yapın ve sonuçları karşılaştırın:

İkinci satır bir başarısızlık değildir: saklama süreleri yeni sürümlerin ya da delete marker'ların oluşturulmasını engellemediği için kilitli sürüm yerinde kalır. Asıl endişe verici olan üçüncü satırdır. S3 konsolu varsayılan olarak x-amz-bypass-governance-retention:true header'ını ekler; dolayısıyla bu izne sahip herkes governance kilidi olan nesneleri birkaç tıklamayla silebilir.

Ardından aynı kalıcı silme isteğini, aynı kullanıcı olarak API ya da CLI üzerinden bu header olmadan gönderin. AWS, governance mode'u geçersiz kılan her istekte bu header'ı zorunlu tutar, dolayısıyla sonuç Access Denied olmalıdır. İstek başarılı olursa bucket'ın saklama modunu ve nesne sürümündeki kilit ayarlarını kontrol edin.

Ardından kilidi kimin geri alabileceğini denetleyin

Politikaları s3:BypassGovernanceRetention iznine izin veren tüm principal'ları listeleyin; rolleri, grupları ve inline politikaları da dahil edin. Aynısını s3:PutObjectLegalHold için de yapın: legal hold'un son kullanma tarihi yoktur ve bu izne sahip herhangi bir kullanıcı hold'ları serbestçe koyabilir ve kaldırabilir.

Her iki izni de bir saldırganın ele geçirmesi makul olan hesaplardan kaldırın. Kaybetmeyi göze alamayacağınız veriler için, bilinçli olarak seçtiğiniz bir saklama süresiyle compliance mode'u değerlendirin.

Test 2: Yedeğe yanlış kimlik bilgileriyle ulaşmayı deneyin

Saldırgan onu yöneten konsolu kontrol ediyorsa, değiştirilemez depolama alanı işe yaramaz. Yedekleme konsoluna ve depolama alanına bir domain admin, bir backup-operator hesabı ve bir cloud IAM kullanıcısı ile giriş yapmayı deneyin; her birinin veri silip silemediğini ya da saklama ayarlarını değiştirip değiştiremediğini kontrol edin.

NCSC rehberi, yedekleme hesapları için şu korumaları öneriyor:

• Privileged Access Workstation'lar ve IP allow listing uygulayan donanım güvenlik duvarları.
• MFA; MFA yönteminin, yedekleri yönetmek için kullanılan cihaza kurulu olmaması.
• Privileged Access Management; böylece yöneticiler yüksek değerli yedekleme sistemlerine doğrudan erişmez.

Yedekleme diskleri ve USB bellekler ağınıza kalıcı olarak bağlı kalmamalı, yedekleme ürünleri de yamalanmalıdır. Bir bulut hizmeti kullanıyorsanız, önceki sürümlerin anında silinmeye karşı korunduğunu ve bu sürümlere geri dönebildiğinizi doğrulayın; çünkü hizmetler çoğu zaman dosyalarınız şifrelenmiş kopyalarla değiştirildikten hemen sonra senkronize olur.

Test 3: Bir şeyi geri yükleyin, kronometreyle

İş biriminin bir gün içinde eksikliğini hissedeceği bir sistem seçin ve onu yedekten temiz, izole bir ortama geri yükleyin; böylece geri yüklenen bir enfeksiyon canlı sistemlere bulaşamaz. Geçen süreyi, kimin ne yaptığını ve birinin bir parolayı, bir lisans anahtarını ya da geri yüklediğiniz sunucularda bulunan bir belgeyi aramak zorunda kaldığı her noktayı not edin.

Geri yükleme yarıda başarısız olursa adımı, geçen süreyi, nedeni ve çözümü kaydedin; ardından o adımdan yeniden başlayın ve kalan süreyi ayrı olarak kaydedin. Sonuçların karşılaştırılabilir olması için adımları denemeler arasında aynı tutun.

Kurtarmadan önce yedekleri yalnızca bilinen temiz cihazlara bağlayın ve dosyaları geri yüklemeden önce kötü amaçlı yazılım için tarayın. Fidye yazılımı fark edilmeden önce yedeklere de kopyalanmış olabilir; bu yüzden temiz görünen bir geri yükleme noktası temiz olmayabilir.

Ölçtüğünüz süreyi iş biriminin tolere edebileceğini söylediği süreyle karşılaştırın. Bu rakamı testten önce sistem sahibinden alın; böylece hedefi sonuca uydurmamış olursunuz. Fidye yazılımından tam kurtarma, mümkünse, birkaç hafta sürebilir; bu nedenle tek bir sistem için ölçtüğünüz süreyi alt sınır olarak değerlendirin.

Kâğıt üzerinde, şirket içi sistemlerin ve bulut yedekleme sunucularının ikisinin de kullanılamaz olduğu ve çevrimdışı yedeklerden yeniden kurulum yapmanız gereken bir durumda neler olacağını ve kritik iş hizmetlerini nasıl ayakta tutacağınızı çıkarın. Playbook'ların, kontrol listelerinin ve iletişim bilgilerinin bilgisayar sistemleriniz olmadan ulaşabileceğiniz bir yerde bulunduğunu doğrulayın. Dışarıdan bir bakış istiyorsanız, olay müdahale hizmetimiz bu tür tatbikatları kapsar.

Nereden başlamalı

1. İş açısından kritik bir sistem seçin ve sahibine ne kadar süre kapalı kalabileceğini sorun. Bu rakamı önce yazın.
2. Versioning ve governance mode'da (asla compliance değil) Object Lock içeren bir deneme S3 bucket'ı oluşturun. Kalıcı silme ve basit silme deneyin, yanıtları kaydedin.
3. Kalıcı silmeyi, s3:BypassGovernanceRetention iznine sahip bir kullanıcı olarak hem konsoldan hem de bypass header'ı olmadan API ya da CLI üzerinden tekrarlayın. Ardından bu iznin ve s3:PutObjectLegalHold izninin tüm sahiplerini listeleyin ve ihtiyacı olmayanlardan kaldırın.
4. Yedekleme konsoluna bir domain admin, bir backup operator ve bir cloud IAM kullanıcısı ile giriş yapmayı deneyin. Giriş başarılı olduysa ayrı bir cihazda MFA ve IP allow listing planlayın. Çevrimdışı bir kopyanın var olduğunu, kalıcı olarak bağlı olmadığını ve bu kopyadan geri yükleme yapıldığını doğrulayın.
5. Seçtiğiniz sistemi, taranmış bir yedekten izole bir ortama geri yükleyin, her adımı zamanlayın ve sonucu 1. adımdaki rakamla karşılaştırın.
6. En büyük açığı kapatın, ardından yedekleme tasarımı her değiştiğinde testleri yeniden çalıştırın.