ABD İç Güvenlik Bakanlığı’nın Siber Güvenlik İnceleme Kurulu (CSRB), Aralık 2021’de açıklanan Apache Log4j güvenlik açığının önümüzdeki on yıl veya daha uzun süre kuruluşlar için önemli bir risk olmaya devam edeceği sonucuna vardı.
Özel sektör ve devlet siber güvenlik uzmanlarından oluşan yeni kurulan kurul, açık kaynak topluluğunun kodunun güvenliğini sağlamak için yeterli kaynağa sahip olmadığını ve özel ve kamu sektörlerindeki paydaşlardan geniş yardım gerektirdiğini belirledi. Bugün yayınlanan bir raporda, kurul, açık kaynak kodunun en büyük tüketicilerinden bazıları olarak federal kurumların açık kaynak güvenliğine katkıda bulunmasını tavsiye etti ve hükümeti ekosistemin güvenliğini artırmak için yatırımları finanse etmeyi düşünmeye çağırdı.
CSRB bir dizi yayınladı 19 üst düzey öneri kuruluşların Log4j ile ilgili saldırılara maruz kalmayı ve ileriye dönük diğer benzer yazılım tedarik zinciri risklerini azaltması için. Kuruluşlara yönelik öneriler, güvenlik açığı bulunan Log4j sürümlerini aramayı ve değiştirmeyi, güvenlik açığı bulunan sürümlerin ortama yeniden girmesini önlemek için süreçler oluşturmayı ve BT varlıklarının ve uygulamalarının doğru bir envanterini korumayı içerir.
Endemik Bir Güvenlik Açığı
CSRB’nin sonuçları ve tavsiyeleri, Log4j güvenlik açığı açıklamasını çevreleyen koşullara ve açık kaynak topluluğu, teknoloji satıcıları ve devlet ve özel kuruluşlardan gelen yanıtlara ilişkin aylarca süren araştırmasına dayanmaktadır.
CSRB Perşembe günü bulgularını özetleyen bir raporda, “Kurul, Log4j’nin ‘endemik bir güvenlik açığı’ olduğunu ve Log4j’nin savunmasız örneklerinin uzun yıllar boyunca sistemlerde kalacağını değerlendiriyor.” Dedi.
Raporda, “Log4j’nin kullanımı beklenenden daha düşük seviyelerde olmasına ve kritik altyapı hedeflerine yönelik büyük bir Log4j saldırısı olmamasına rağmen, tehdit azalmadı” denildi. “Önemli risk devam ediyor.”
Luta Security’nin kurucusu ve CEO’su ve bir CSRB üyesi olan Katie Moussouris, “CSRB raporunun en önemli yönleri, birbirine bağlı karmaşık dünyamızın gerçekliğini anlayan hiç kimseyi şaşırtmamalıdır” diyor. “Tehditlerle mücadeleye yardımcı olmak için, ihtiyaç duymamıza rağmen güvenlik açısından yeterince desteklenmeyen açık kaynak teknolojisine güveniyoruz” diyor.
DHS, bir yanıt olarak Şubat 2022’de CSRB’yi kurdu. siber güvenlik İcra Emri Biden yönetimi geçen Mayıs ayında yayınladı. CSRB’nin görevi, benzer olayları önlemek için ulusal düzeyde iyileştirmeler yapılabilmesi için hükümetten ve özel kuruluşlardan güvenlik uzmanlarının önemli güvenlik olaylarını incelemesini ve değerlendirmesini sağlamaktır. Log4j incelemesi, CSRB’nin ilk göreviydi.
Apache Log4j, hemen hemen her Java uygulama ortamında bulunan açık kaynaklı bir günlük kaydı aracıdır. Kasım 2021’de Çin’in e-ticaret devi Alibaba ile bir güvenlik mühendisi bir güvenlik açığı bildirdi (CVE-2021-44228) Log4j’de bakımını yapan Apache Software Foundation’a (ASF) gönderir. Java Adlandırma ve Dizin Arabirimi (JNDI) adı verilen veri depolama ve alma için bir Log4j bileşenindeki güvenlik açığı, temel olarak saldırganlara güvenlik açığı bulunan sistemlerin tam uzaktan kontrolünü almanın bir yolunu verdi. 9 Aralık 2021’de güvenlik açığının kamuya açıklanması, istismar edilmesinin kolay olması, her yerde mevcut olması ve feci sonuçlara yol açması nedeniyle yaygın endişeleri tetikledi.
CSRB’nin raporunda vurguladığı bir diğer önemli, devam eden sorun, bileşenin birçok ortamda ne kadar derine gömülü olabileceğinden dolayı Log4j’nin savunmasız sürümlerinin genellikle kolayca tespit edilememesidir.
Önlenebilir Bir Felaket mi?
CSRB incelemesi, açık kaynak topluluğunun bireysel bir üyesinin, savunmasız JNDI bileşenini 2013’te Log4j ile dahil edilmek üzere gönderdiğini gösterdi. Log4j ekibi bileşeni kabul etti ve daha sonra Log4j kullanan binlerce uygulamaya entegre edildi. Kurul, Log4j ekibinin kodu gözden geçirecek güvenlik becerilerine sahip biri olması veya güvenli kodlama uygulamaları konusunda eğitim almış olması durumunda güvenlik açığının 2013 yılında tespit edilebileceğini belirledi.
Kurul, “Ne yazık ki, böyle bir incelemeyi gerçekleştirecek kaynaklar, 2013’te bu açık kaynak projesini yöneten gönüllü geliştiriciler için mevcut değildi.” Dedi.
Müfettişler, Log4j güvenlik açığı ifşasına en etkili şekilde yanıt veren kuruluşların, aynı zamanda etkin varlık ve risk yönetimi süreçlerine sahip olan ve kuruluş çapında hızlı eylemi harekete geçirecek kaynaklara sahip olan kuruluşlar olduğunu buldu. Ancak CSRB, çok az kuruluşun bu tür bir yanıt verebildiğini veya bu büyüklükteki bir güvenlik açığına yanıt vermek için gereken hıza sahip olduğunu buldu. Sonuç olarak, hem güvenlik açığından kaynaklanan risk değerlendirmelerinde hem de bunu yönetmelerinde önemli bir gecikme yaşandı. Birçoğunun, ASF’nin yayınladığı Log4j’nin sabit sürümüne yükseltme yapıp yapmamaya – ve olası uygulama kesintilerinden kaynaklanan iş kesintisi riskine – veya güvenlik açığına dokunulmadan bırakmaya ve saldırı riskini almaya karar vermesi gerekiyordu.
Raporda, “Log4j etkinliği, güvenlik açığı yanıt uygulamaları ve genel siber güvenlik hijyenindeki temel benimseme boşluklarını vurguladı” dedi.
Moussouris, Log4j’nin kuruluşların kritik ihtiyacın altını çizdiğini söyledi. varlıklarını bilmek ve kritik sistemlerinde hangi yazılım sürümlerinin çalıştığı. “Halkı şaşırtabilecek olan şey, çok az sayıda kuruluşun kritik varlıklarının ve ağlarında hangi yazılımların çalıştığının güncel bir listesine sahip olmasıdır” diyor. “Bu değişene kadar bir sonraki kütüphane olayına yanıt vermeye hazır değiliz.”
CSRB’nin raporundan çıkan önemli bir paket, açık kaynak güvenliği etrafında daha koordineli eyleme duyulan ihtiyaçtır. Genellikle, Log4j gibi yaygın olarak kullanılan açık kaynaklı bileşenler, güvenlik için çok az dikkate alınarak gönüllü ekipler tarafından sağlanır. Genellikle, rapor edilen güvenlik açıklarını araştırmak ve bunları ele almak için koordineli güvenlik açığı açıklama ve müdahale ekiplerine sahip değildirler.
CSRB, “Log4j gibi güvenlik açıklarının ortaya çıkmasının tekrarını azaltmak için, kamu ve özel sektör paydaşlarının açık kaynak topluluğunu ileriye doğru destekleyebilecek merkezi kaynak ve güvenlik yardım yapıları oluşturması esastır.” Dedi.
Açık Kaynak Ekosistemi için Artırılmış Destek
Google’da altyapıdan sorumlu başkan yardımcısı Eric Brewer, raporun kuruluşların ortamlarında açık kaynak kullanımına nasıl yaklaşmaları gerektiğine dair olumlu ve ayrıntılı bir görüş sağladığını söylüyor. “Açık kaynak kullanıyorsanız, başkalarının güvenlik sorunlarını sizin için sihirli bir şekilde düzeltmesini bekleyemezsiniz” diyor. Açık kaynak kodunun kullanımında örtük olan, kuruluşların yazılımı “olduğu gibi” tükettiği gerçeğidir. Brewer, bunun, onunla ilişkili riski azaltma sorumluluğunu da paylaşmaları gerektiği anlamına geldiğini söylüyor.
CSRB’nin açık kaynak güvenliğine yönelik artan yatırım çağrısını memnuniyetle karşılıyor ve ayrıca büyük açık kaynak projeleri için küratör olarak hizmet edebilecek daha fazla kuruluşa ihtiyaç olduğunu söylüyor. Google gibi büyük şirketler, kendilerinin tükettiği açık kaynak kodundaki güvenlik açıklarını düzeltebilir ve daha sonra diğerlerinin güvenle kullanabilmesi için küratörlü yazılımı sunabilir. Diğer örnekler olarak, büyük açık kaynak projelerinin küratörlüğünde sürümlerini sunan Red Hat ve Databricks gibi diğer kuruluşlara işaret ediyor.
Synopsys Siber Güvenlik Araştırma Merkezi’nin ana güvenlik stratejisi olan Tim Mackey, “Açık kaynaklı yazılımlar temelde ticari yazılımlardan farklı şekilde yönetiliyor, ancak açık kaynaklı yazılımlar ticari yazılımların başarısında kilit bir rol oynuyor” diyor. Bir açık kaynak bileşenindeki bir sorun hakkında kendilerini uyarması için ticari bir satıcıya güvenen kuruluşlar, satıcının açık kaynak kullanımlarını düzgün bir şekilde yönettiğini ve etkilenen yazılımlarının tüm kullanıcılarını belirleyip uyarabildiğini varsaymaktadır. Mackey, riski azaltmak için “yazılım tüketicileri, kendilerine verilen yazılımın yamalanmamış güvenlik açıkları içerip içermediğini doğrulamak için bir güven ama doğrula modeli uygulamalıdır” diyor.
