Felaket kurtarma için planlamaya nasıl başlanır?


Büyük ölçekli bir siber güvenlik olayından kurtulmak için bir müşterimle çalışırken bir Pazar sabahı saat 3’te sık sık düşündüğüm ünlü bir alıntı var: “Hazırlanamamak, başarısızlığa hazırlanın.” Hangi müşterilerin bir felaket kurtarma ön planlaması yaptığı ve hangilerinin yapmadığı acı verici bir şekilde açık.

felaket kurtarma planlamasını başlat

Olay müdahale çalışmalarının çoğunda, tanımlama, kontrol altına alma ve ortadan kaldırmanın bir araya gelmesi kadar kurtarma maliyetleri de vardır. Bununla birlikte, insanlar, stres ve itibar kaybı açısından maliyeti akıl almaz.

İnsanların öfkeyle işlerinden ayrıldığına tanık oldum, bir denizciyi utandıracak bir odaya yayılan bir dil duydum ve bir keresinde bir hukuk firmasının CEO’sunun kendi CFO’suna yumruk attığını gördüm – hepsi bir işi geri almanın stresi yüzünden büyük bir siber güvenlik ihlalinden sonra çalışır durumda.

Birçok şirket bulutu bu durumdan çıkış yolu olarak görüyor. Bırakın Azure, AWS, Google veya Rackspace bununla ilgilensin! Bulut sağlayıcıları yedekleme ve kurtarma avantajlarıyla birlikte geldiğinden, bu bir dereceye kadar işe yarayabilir, ancak tüm yumurtalarınızı tek bir sepette toplama riski vardır. Şirketler – en küçüğü bile – daha büyük resmi düşünmeli ve bir dizi farklı senaryodan sonra toparlanmayı planlamalıdır. Dikkatsiz kullanıcılar tarafından silinen tek bir dosyanın nasıl kurtarılacağından tam bir ağın yeniden oluşturulmasına kadar. En önemlisi, herhangi bir kurtarma planı sadece “teknik konularla” ilgili olamaz: İK, Halkla İlişkiler ve Hukuk ile BT ekibinin hepsinin oynayacağı bir rol vardır.

Kurtarma planlamasının değeri

Siber güvenlik dünyasında bu, felaket kurtarma planlaması, kriz yönetimi veya yedekleme ve kurtarma politikası olarak bilinir. Ancak adı ne olursa olsun, her şey bir BT ağının kurtarılması için test edilmiş ve sağlam bir süreç ve nihayetinde normal iş haline dönüş sağlayan olay öncesi planlamaya indirgenir. Benim dünyam ihlal sonrası kurtarmaya odaklanmış olsa da, şirketlerin bilgisayar korsanlarıyla ilgili olmayan bir yanıtı hesaba katması gerekiyor. Veri merkezinizin elektriği kesilirse ne olur, jeopolitik koşullar değişirse ne olur ve bulut sağlayıcınız tüm yumurtalarınızı ezerse ne olur?

İnterneti ilk keşfeden 90 yaşında biri gibi görünme riskini göze alarak, bugünlerde her şey birbirine bağlı. Bu, olağanüstü durum kurtarma planınızın yalnızca işinizi (veya işinizi) kurtarmakla kalmayıp, her gün işinize güvenen yüzlerce, binlerce, hatta milyonlarca müşterinin mışıl mışıl uyuyabilmesini sağlayacağı anlamına gelir.

Geçenlerde Financial Times’da çıkan bir makale, “2020’de Bank of England araştırması, Birleşik Krallık merkezli bankaların ve sigorta şirketlerinin yüzde 65’inden fazlasının yalnızca dört bulut hizmetine güvendiğini ortaya çıkardı.” Bu sağlayıcılardan yalnızca biri çevrimdışı olursa, İngiltere merkezli her bankanın kendi yedekleme ve kurtarma planı olur mu? AB böyle düşünmüyor ve bankaları kurtarma planlarına bunu dahil etmeye ve bir siber saldırıdan ne kadar çabuk kurtulabileceklerini kanıtlamaya zorlayacak yeni düzenlemeler getirmeyi planlıyor.

Geriye bakmak

WannaCry öncesine geri dönersek, o zamanlar yaygın olarak bilindiği şekliyle “yedekleme ve kurtarma” basitti. Şirketlerin yalnızca fiziksel sistem çökmeleri konusunda endişelenmesi gerekiyordu, bu nedenle, işinizi teslim eden 100 sunucunuz varsa, hepsini yedeklediniz (ideal olarak site dışında) ve ardından bir şeyler ters gittiğinde eşleşen bir sunucu getirip kurtardınız. Basit.

Fiziksel hasar nedeniyle her şeyin bir anda başarısız olma riski çok zayıftı. Evet, bazen veri merkezleri iflas etti ama bu yüzden tamamen bağımsız şirketler tarafından yönetilen farklı veri merkezlerinde ikili kurulumlarınız oldu. Bazı büyük kuruluşlar, birden çok konuma yayılmış üç dijital veri kopyasıyla daha gelişmiş yaklaşımlara sahipti. Ancak bu birçok KOBİ için norm değildi.

Siber güvenlik, yedekleme ve kurtarmada gerçekten çok büyük bir faktör değildi. Geçmişte bazı yıkıcı solucan benzeri virüsler salıverilmişti: 2003’te SQL Slammer, 2004’te Sasser ve aynı yıl Mydoom (bir tür solucan). Yine de, internetteki virüslerin çoğu mümkün olduğu kadar çok soruna yol açacak şekilde tasarlandı, ancak tüm şirketleri çökertmek için değil. Fidye yazılımı da henüz emekleme aşamasındaydı ve bir kuruluşta yalnızca bir veya iki Windows makinesini etkilediği ve iş dünyasında nadir olduğu için küçük bir risk olarak görülüyordu.

Binlerce sistemi aynı anda şifreleyecek altyapıya sahip siber çeteler olmadığı için kimse endişelenmedi. Bulut hizmetlerinin popülaritesi artmaya başladıkça, gelecek pembe görünmeye başladı. Tamamen bir bulut dünyasına geçiş yapmaktan, son kullanıcı dizüstü bilgisayarlarının bakımı dışında her şeyi dış kaynaklardan temin etmekten bahseden müşterilerim vardı. Mutluluk dolu masum bir zamandı.

Sonra 2017’de, WannaCry dünya çapındaki organizasyonları alt üst edip çok fazla zarar verdiğinde her şey değişti. Şirketler tüm BT sitelerini yok etti, hastaneler Windows’un eski sürümlerini çalıştırıyor ve ışıkları açık tutmakta zorlanıyordu ve dünyanın dört bir yanındaki BT ekipleri toparlanmak için aylar ve milyarlarca dolar kaybetti. Birçok şirket için ufuk açıcı bir deneyimdi ve dünyanın dört bir yanındaki CEO’lar aynı soruyu sormaya başladı: “Benzer bir saldırıdan ne kadar çabuk kurtulabiliriz?”

BT güvenlik endüstrisinin ve siber suçların karanlık dünyasının WannaCry’den sonra geri dönülmez bir şekilde değiştiğini söylemek abartı olmaz. Siber suçlular, bir şirkete sızabileceklerini ve fidye yazılımını saatler içinde yüzlerce hatta binlerce cihaza yayabileceklerini öğrendiler. Bununla birlikte, milyonları aşan büyük ödüller geldi, mükemmel bir fırtınada bu, kripto para biriminin yeni ütopik dünyası tarafından kolaylaştırıldı.

Bu durum, bazı büyük şirketlerin toparlanmayı ve ön planlamayı düşünmeye başlamasına neden oldu. 2017’den bu yana, ağların tamamen yeniden oluşturulması veya yedeklerden tamamen kurtarılması gereken ve bazı korkunç durumlarda teyp yedeklerinden kurtarılması gereken yüzlerce anlaşmanın parçası oldum. WannaCry’den önce, bu kadar etkili olan herhangi bir kurtarma süreci düşünemiyorum. Her zaman sorunlara neden olan şey aynıdır: zaman veya daha doğrusu zaman eksikliği.

En kötü durum senaryosu

Çok fazla ön planlama yapmadan bir ağı yeniden kurmanın ne kadar süreceğini hesaplamak imkansızdır. Biliyorum çünkü yapmaya çalıştım. Son 12 ayda, kurtarma planı olmayan ve tamamen teyp yedeklemelerine güvenen beş müşteriyle çalıştım. Bir örnekte, yüzlerce terabaytlık veriyi kasetlerden almak bir aydan fazla sürdü, ardından kurtarma çalışması başladı. Başka bir örnekte, müşterinin teyp yedeklemelerini kurtarmak için fazladan depolama alanı da yoktu, bu yüzden iyi bilinen bir sunucu üreticisine gidip maliyeti 250.000 £’u aşan çok sayıda ekipmanı panikle satın almak zorunda kaldık. Ve tüm bunlar, tek bir sistem bile yeniden inşa edilmeden önce oldu.

Bu, en iyi ihtimalle stresli olabilir, ancak bir yönetim kurulunun güncellemeler için size bağırmasını sağlayın ve baskı, insanların sağlığını etkileyecek kadar kötüleşebilir. Her durumda, ikinci sistemler ve müşteri teslimatı bozuldu. Kızgın müşteriler sosyal medyaya taşındı. En son örneklerimin hiçbiri önemli bir toplumsal etkiye sahip değildi, ancak aynı durumu bir bankaya, yerel makama uygulayın veya son İrlanda sağlık hizmeti fidye yazılımı saldırısına bakın ve durum ve kurtarma planlaması eksikliğinin gerçek hayattaki sonuçları var.

Kurtarma için planlama

Peki, şirketler sorunlardan kaçınmak için ne yapmalı? Mevcut önerilen AB yasaları geçerliyse, finansal hizmet şirketlerinin harekete geçmekten başka seçeneği olmayabilir. Bence bu sadece olumlu bir şey olabilir. Sonunda bulut bilgi işlem norm olacak ve beraberinde yepyeni bir dizi sorunu getirecek. İşletmeler, teknolojideki yeni değişikliklere tepki vermekte her zaman yavaştır, bu nedenle doğru yönde küçük bir düzenleme dürtüsü iyi bir şeydir. Ancak diğer sektörlerdeki işletmeler de bekleyip görmemeli. İster siber saldırılar için ister başka türlü olsun, felaketten kurtarma için önceden planlama yapmanın size çok para kazandırabileceği tartışılmaz bir gerçektir.

Felaket kurtarmayı planlarken kendinize sormanız gereken milyonlarca soru var, çünkü bu hızlı ve kolay bir iş değil ve pek çok insanın bunu yapmamasının nedeninin bu olduğundan şüpheleniyorum. İyi bir başlangıç ​​noktası, ağınızı tamamen yeniden oluşturmanızın ne kadar süreceğini değerlendirmektir. En kötü durumu hayal edin, her şey çöktü ve sahip olduğunuz tek şey yedekleriniz. Ne yapıyorsun, hangi sırayla yapıyorsun, önceliklerin neler ve ne kadar sürecek? Çoğu durumda bunu gerçek zamanlı olarak çalıştırmak çok maliyetli olacaktır, ancak teorik olarak hepsini halletmek kesinlikle iyidir.

Kurtarma işleminize güç katmak için sahip olduğunuz teknolojiye bakın, hangi yedekleme çözümüne sahipsiniz? Yedeklerinizin güvenliği çok önemlidir, ancak bu tamamen başka bir şeydir. Güvende olduklarını ve saldırganlar tarafından yok edilmediklerini varsayarsak, restorasyon sürecini başlatmak ne kadar sürer? Bulut tabanlıysanız ve sanal sistemlerle bulut uygulamalarının bir karışımını çalıştırıyorsanız, ikisi nasıl etkileşim kurar? Şimdi diğer meslektaşlarınızla konuşmanız gerekiyor: BT ekibi ve diz boyu teyp yedeklemeleri yaparken hukuk, İK, PR ve hatta bina yöneticileri ne yapacak? Bu, şirketinizin felaket kurtarma planının başlangıcı olacaktır.

Ayrıntılı bir planınız ve bunun ne kadar süreceğine dair bir tahmininiz olduğunda, hepsini anlaşılması kolay bir plana yazmanız yeterlidir. Roller ve sorumluluklar açık ve kabul edilmiş olmalı, iletişim yolları tanımlanmalı (kim, ne zaman ve nasıl) ve dahil olan herkes kullanıma sunulmadan önce planı okumalı ve kabul etmelidir. Artık herkes, tam felaket kurtarma için zaman çerçevesinin kabul edilebilir olup olmadığını tartışabilir. Çok uzunsa, bunun neden olduğuna bakmaya başlayabilirsiniz: insanlar, süreç veya teknoloji. Sonunda kazanan riske karşı maliyet formülüne ulaşacaksınız.

Artık “acil durumda camı kırın” çözümüne sahip olduğunuza göre, geriye doğru çalışmaya başlayın. Yalnızca bir veri merkezi çökerse ne yaparsınız, bir bulut sağlayıcı çökerse ne yaparsınız, ya DNS, DHCP, AD… ve son olarak, ya hesaplardaki Sara yanlışlıkla bir hesap tablosunu silerse? Bu konuda fazla strese girmeyin çünkü her senaryoyu düşünemezsiniz. Ancak, en yaygın senaryoları ele almak ve saldırı ayak izinize ve risk profilinize bakmak çok yardımcı olabilir.

Gelecek için bugünden yatırım yapın

En küçük işletme bile bir dizi kesintiden ağır şekilde etkilenebileceğinden, bu düzeyde bir ön planlama, büyük bankaların ve kurumların rezervi olmamalıdır. İşletme ne kadar küçük olursa, uzun vadeli kapalı kalma süresinin neden olabileceği mali ve itibari zarardan kurtulma olasılığının o kadar düşük olduğuna dair savunulacak bir argüman bile var. Maliyetin de engelleyici olması gerekmez. Evet, tüm bunları sizin için yapması için bir danışmanlık firmasına girmek harika olabilir, ancak aynı zamanda maliyete on binlerce sterlin ekler. Günün sonunda, ağınızı sizden daha iyi kim bilebilir?

Önceden planlama yapsanız bile işler yine de ters gidecek ve stres seviyeleri yavaş yavaş artacaktır – bu kaçınılmazdır. Ancak, ön planlama olmadan her şeyin çok daha kötü olacağını ve kimsenin patronunu yumruk yumruğa kavga ederken görmesine gerek olmadığını söylediğimde bana güvenin.



Source link