Tehdit azaltma, bir dereceye kadar siber güvenlik uzmanlarını içeren bir uzmanlık görevi olsa da, günlük tehdit azaltma genellikle sistem yöneticilerine düşer. Ancak bu sistem yöneticileri için bu kolay bir iş değildir. Kurumsal BT’de, sistem yöneticileri ekiplerinin geniş bir görev alanı ancak sınırlı kaynakları vardır.
Sistem yöneticileri için büyüyen ve sürekli hareket eden bir tehdide karşı önlem almak için zaman ve kaynak bulmak zordur. Bu makalede, kurumsal tehdit azaltmanın ima ettiği zorlukları özetliyoruz ve otomatikleştirilmiş, amaca yönelik olarak oluşturulmuş azaltma araçlarının neden ileriye dönük yol olduğunu açıklıyoruz.
Tehdit yönetimi ezici bir görevdir
Tehdit yönetimi içinde çalışan bir dizi uzman vardır, ancak tehdit yönetimi stratejilerinin pratik uygulaması genellikle sistem yöneticilerine düşer. Yama yönetimi, izinsiz giriş tespiti veya bir saldırıdan sonra düzeltme olsun, sistem yöneticileri genellikle işin yükünü taşır.
Tehdidin büyüyen doğası göz önüne alındığında, bu imkansız bir görevdir. Sadece 2021’de, 28.000 güvenlik açığı açıklandı. Bu o kadar büyük bir sayı ki, aslında büyük bir kısmı hiçbir zaman bir CVE’ye atanacak kadar ileri gidemedi. Bu, özellikle CVE’leri izlemeye, sistemlerimizde varlıklarını test etmeye ve belirli CVE numaralarından bahseden yamaları dağıtmaya lazer odaklı bir endüstri için geçerlidir. Savunmasız olduğunu bilmediğin şeye karşı koruyamazsın. Belirli bir güvenlik açığına eklenmiş bir CVE yoksa ve tüm araçlarınız/zihniyetiniz/süreçleriniz CVE’lere odaklanmışsa, bir şeyler başarısız olacaktır. Bir güvenlik açığına CVE atanmamasının nedenleri şunlardır: birçok ve bu yazının kapsamı dışındadır, ancak bunların hiçbiri güvenlikte yapılması gereken işi azaltmaz.
Bir kuruluşun üç haneli bir sistem yöneticisi ekibi olsa bile, sürekli büyüyen bu güvenlik açıkları listesini takip etmek zor olurdu. Bir güvenlik açığının altyapınızda çalışan ikincil bir sistemi çok açık olmayan bir şekilde etkileyebileceği etkileşimlerden bahsetmiyoruz bile.
Zamanla, güvenlik açıklarından oluşan bir “arka plan gürültüsüne” dönüşür. Yamanın düzenli, haftalık veya belki günlük olarak gerçekleştiğine dair bir varsayım var – ancak gerçekte, CVE duyurularındaki ilgili, ayrıntılı bilgiler hiçbir zaman akıllara gelmez.
Bunalmış takımlar risk alır
Düzeltme eki dahil olmak üzere güvenlik görevlerinin böylesine ezici bir alıştırma haline gelmesiyle, sistem yöneticilerinin bazı kısayolları kullanmaya başlaması şaşırtıcı değil. Belki bir sistem yöneticisi, yeni bir istismar ile ikincil bir sistem arasındaki etkileşimi gözden kaçırıyor veya en son düzeltmeyi dağıtmadan önce yamaları düzgün bir şekilde test etmeyi ihmal ediyor – bunların hiçbiri ağ çapında bir erimeyi önleyemeyebilir.
Dikkatsiz bir şekilde ele alındığında, yama gibi güvenlik yönetimi görevlerinin sonuçları olabilir. Küçük bir değişiklik geri gelecek ve güvenlik ekiplerini birkaç gün, hafta veya aylar sonra beklemedikleri başka bir şeyi kırarak rahatsız edecek.
“Delikleri kapatmak”, bu bağlamda bir sorun kadardır. Örneğin, Log4j varsayılan yapılandırmasını değiştirmenin kolayca önemli bir azaltma sağlayabileceği Log4j güvenlik açığını ele alalım. Bu bariz ve mantıklı bir adım ama asıl soru şu: sysadmin ekibinin görevi tamamlamak için kaynakları var mı? Gerçekleştirmek zor olduğundan değil başlı başına – ancak tüm sistem filosunda log4j’nin her kullanımını izlemek zordur, ayrıca gereken iş ek olarak diğer tüm düzenli faaliyetlere.
Ve yine, yamaya işaret ederek, bunu sürekli olarak yapmak için gereken kaynaklar genellikle orada değildir. Yama uygulamasının, temel alınan hizmeti yeniden başlatmayı gerektirdiği gerçeği göz önüne alındığında, yama özellikle zordur. Yeniden başlatmalar zaman alıcı ve yıkıcıdır ve kritik bileşenler söz konusu olduğunda yeniden başlatma gerçekçi olamaz.
Net sonuç, temel güvenlik görevlerinin basitçe yapılmaması ve sistem yöneticilerinin güvenliğin olması gerektiği gibi olmadığı konusunda rahatsız edici bir his uyandırmasıdır. Sızma testi ve güvenlik açığı taraması da dahil olmak üzere güvenlik izleme için de geçerlidir. Evet, bazı kuruluşların bu görevi yerine getirmek için uzmanları olabilir – hatta kırmızı ekipler ve mavi ekipler oluşturacak kadar ileri gidebilirler.
Ancak, çoğu durumda, güvenlik izleme, kaçınılmaz olarak aşırı yüklenecek ve sonunda alacak olan sistem yöneticileri için başka bir görevdir.
Ve daha da kötüye gidiyor
Olması gereken tek şeyin sistem yöneticilerinin yükün önüne geçmesi olduğunu düşünebilir – kaslarınızı gevşetin ve sadece yapın. Sistem yöneticileri, biriktirme listesi üzerinde çalışarak, belki biraz ekstra yardım alarak iş yükünü yönetebilir ve hepsini halledebilir.
Ama burada ufak bir sorun var. Güvenlik açıklarının sayısı hızla artıyor – ekip bilinen sorunlarla ilgilendikten sonra, şüphesiz daha da fazlasıyla karşılaşacaktır. Ve güvenlik açıklarının hızı hızlanıyor, her yıl daha fazla rapor ediliyor.
Buna ayak uydurmaya çalışmak, ekiplerin boyutunun her yıl %30 oranında artması anlamına gelir. Bu, manuel yaklaşımlara sahip bir insan ekibinin kazanacağı bir savaş değil. Açıkçası, alternatiflere ihtiyaç var, çünkü bu nitelikteki sürekli bir savaş, neredeyse üstel bir şekilde her yıl ekip boyutlarını artırarak kazanılmayacaktır.
Tehdit yönetimi otomasyonu anahtardır
Tabii ki bilgi işlemin iyi yanı, otomasyonun genellikle yapışkan kaynak kısıtlamalarından bir çıkış yolu sağlamasıdır – ve tehdit yönetiminde de durum böyledir. Aslında, büyüyen tehdit ortamına karşı herhangi bir ilerleme kaydetme şansı istiyorsanız, güvenlik açığı yönetimi genelinde görevler için otomasyon dağıtmak çok önemlidir. Yeni güvenlik açıklarının izlenmesinden yama ve raporlamaya kadar.
Bazı araçlar belirli yönlerde yardımcı olurken, diğerleri tüm bu yönlerde yardımcı olacaktır, ancak araç daha kapsayıcı hale geldikçe araçların etkinliği düşme eğilimindedir. Daha özel araçlar, belirli işlevlerinde, her şeyi tek seferde yaptığını iddia eden araçlardan daha iyi olma eğilimindedir. Bunu Unix araç felsefesi olarak düşünün – her şeyi aynı anda yapmaya çalışmak yerine bir şeyi yapın ve onu iyi yapın.
Örneğin, yama otomatikleştirilebilir ve otomatikleştirilmelidir. Ancak yama, sistem yöneticilerine tutarlı bir şekilde ve minimum kesinti ile yama yaparak yardımcı olabilecek özel bir araca ihtiyaç duyan güvenlik görevlerinden biridir.
Yarım yamalak bir yaklaşım işe yaramaz çünkü bakım pencerelerinin kabulü yama uygulamasını yine de engelleyecektir. Bu, BT ekiplerinden, kuruluşun iş operasyonlarını etkilemeden yeni tehditlere neredeyse gerçek zamanlı olarak yanıt verme esnekliğini ortadan kaldıracaktır. Bu gereksinimler için mükemmel bir uyum, aşağıdaki gibi araçlar aracılığıyla canlı yama uygulamasıdır: TuxCare’in KernelCare Enterprise aracı Linux dağıtımları için otomatik, kesintiye yol açmayan, canlı yama sağlar.
Tabii ki, otomatikleştirilmesi gereken sadece yama değil. Siber suçluların güvenlik açıklarını araştırmak için otomasyonu kullanması gibi, teknoloji ekipleri de otomatik, sürekli güvenlik açığı taramasına ve sızma testine güvenmelidir. Bu otomasyon alanı içinde ayrıca güvenlik duvarları, gelişmiş tehdit koruması, uç nokta koruması vb. yer almalıdır.
Saklanacak güvenli bir yer yok
Açıkça, tehdit sorunu daha da kötüleşiyor ve çok hızlı bir şekilde – gerçekten de bu sorunları manuel olarak çözmek istiyorlarsa, kuruluşların güvenlik ekiplerini büyütmeyi umabileceklerinden çok daha hızlı. Kullanılan çözümler açısından belirli bir köşede oturmak da herhangi bir teselli sağlamaz, çünkü kısmen çözümler artık birçok platformda paylaşılan kodla o kadar entegredir ki tek bir güvenlik açığı neredeyse evrensel bir etkiye sahip olabilir.
Ayrıca, son araştırmaların bulduğu gibi, en savunmasız ürünlerin ilk on listesi bazı önemli ürünleri hariç tuttu. Örneğin, daha önce en savunmasız işletim sistemlerinden biri olarak görülen Microsoft Windows, ilk on içinde bile değil – bunun yerine Linux tabanlı işletim sistemleri hakim. Daha güvenli olduğu düşünülen alternatiflere güvenmek iyi bir fikir değil.
Tek gerçek güvenliğin güvenlik otomasyonunda nasıl bulunacağının altını çiziyor. Güvenlik açığı taramasından yama oluşturmaya kadar, otomasyon, gerçekten bunalmış sistem yöneticilerinin bir patlama durumu üzerinde bir dereceye kadar kontrol sahibi olmalarına yardımcı olabilecek tek yoldur – aslında, tek yol budur. yönetilebilir çözüm.