İşletmeler ayrıntılı önerileri takip edebilir ve mevcut yamaları uygulayabilir ve log4j'ye anında yanıt olarak en iyi uygulamaları uygulayabilir. Ancak ikinci bir adımda, yazılım tedarik zincirleriyle ilgili süreçlere genel bir bakış atmalıdırlar.
Trend Micro Avrupa IoT Güvenlik Evanjelisti Udo Schneider, sonuçta Log4Shell bile, güvenlikle ne kadar ilgili olursa olsun, yazılım tedarik zincirindeki "yalnızca" hatalı bir bileşendir" diyor.
Log4Shell - Yazılım tedarik zincirinizi biliyor musunuz?
Elbette, Log4Shell güvenlik açığının oluşturduğu kritik tehdit, anında yanıt verilmesini gerektirir. Ancak ikinci adımda, şirketler genellikle kendilerine yazılım tedarik zincirleri ve belgelenmiş (?) bağımlılıklarla ilgili süreçler hakkında sorular sormak zorundadır.
Birkaç gün önce bilinen Log4Shell güvenlik açığı herkesin ağzında ve dünyanın dört bir yanındaki güvenlik uzmanlarını tetikte tutuyor. BSI, "son derece kritik bir tehdit durumundan" bahsediyor çünkü savunmasız Log4J kitaplığı, tabiri caizse, Java ortamlarında "log standardı". Buna göre binlerce uygulamada ve internet hizmetlerinde de kullanılmaktadır. Ek olarak, güvenlik açığının kötüye kullanılması kolaydır ve çoğu durumda uzaktan yararlanılabilir ve sonuçta keyfi komut yürütülmesine izin verilir. Siber güvenlik açısından gerçek bir kabus! Kuruluşlar, ayrıntılı önerilerimizi takip edebilir ve mevcut yamaları uygulayabilir ve anında müdahale için en iyi uygulamaları uygulayabilir. Ancak ikinci bir adımda, yazılım tedarik zincirleriyle ilgili süreçlere genel bir bakış atmalıdırlar. Sonuçta Log4Shell bile, güvenlik açığı ne kadar güvenlikle ilgili olursa olsun, yazılım tedarik zincirindeki "yalnızca" hatalı bir bileşendir.
Hatalı yapı taşı Log4Shell
Yazılım tedarik zincirlerini ve bağlamlarını anlamak için elektronik ürünlerin imalatı gibi "gerçek" dünyaya bakmak yardımcı olur. Montajlar için sözde "malzeme listeleri" (BOM – Malzeme Listesi) olağandır. Tek bir devre kartına montaj olarak bakarsanız, uygun parça listesi dirençler, kapasitörler, diyotlar, IC'ler ve çok daha fazlası gibi kullanılan tüm bileşenlerin bir listesini içerir. Her bileşen için kesin parametreler, üreticiler, fiyatlar, tedarik kaynakları ve nihai olarak seri numaraları veya en azından parti bilgileri de saklanır.
Bileşenlerden birinin üreticisinden, bir partinin belirli bileşenlerinin belirtilen sıcaklık değerlerine uymadığına dair bilgi varsa, tam olarak hangi kartların (her biri kendi seri numarasına sahip) etkilendiğinin izini sürmek mümkündür a) ve b ) eyleme gerek olup olmadığı. Uygun önlemlerin alınması gerekiyorsa, hangi düzeneklerin etkilendiği bilgisi (seri numarasına göre) elbette çok yardımcı olur. Nihayetinde, bu prosedür, CERN'deki LHC gibi devasa kurulumlarla sonuçlanana kadar neredeyse istediğiniz gibi "montajlar" ile devam eder. Bu kadar büyük bir makinede bile küçücük bir SMD bileşeninin arızalanması tüm makinenin arızalanmasına neden olabilir. Örneğin, hatalı partiler öğrenilirse, nihayetinde kurulu her bir direnci doğrulayabilmeniz gerekir.
Yazılım Malzeme Listesi (SBOM)
Yazılım tedarik zincirleri tam olarak böyle çalışır, yani SBOM'lar” — ve özellikle Log4Shell'e dönersek: Bu boşluktan etkilenip etkilenmediğinizi hemen söyleyebilir misiniz? Log4J kullanan kendi yazılımınızla, soru belki hızlı bir şekilde cevaplanabilir. Genellikle GitHub veya GitLab gibi SCM hizmetleri bile bu tür işlevleri doğrudan sunar. Peki ya geçici bağımlılıklar? Kullandığınız bir üçüncü taraf kitaplığı dahili olarak Log4J kullanıyor mu? Veya daha da kötüsü - kullandığınız bir kitaplık, Log4J kullanan bir kitaplığa bağlı (vb.) bir kitaplık kullanıyor mu? Bir servis sağlayıcının satın aldığı yazılım Log4J'ye mi dayanıyor? Satın aldığınız bir bulut hizmeti Log4J kullanıyor mu?
SBOM içeriği (Resim: Trend Micro).
SBOM'larla boğuşmanızı gerektiren yanıtlara ihtiyaç duyan sorular üzerine sorular. Log4Shell, yazılım tedarik zinciri belgelenmediğinde ortaya çıkan sorunları açıkça gösterir. Ama kanmayın. Log4Shell şu anda kesinlikle en kötü durum senaryosu. Ancak doğrudan güvenlikle ilgili olmayan basit "arızalarda" bile etkilenip etkilenmediğiniz sorusu önemlidir!
Belge bağımlılıkları
Temel olarak, SBOM'lar bağımlılıkları belgelemekle ilgilidir. Bunlar, yazılım (bileşenler) biçimindeki bağımlılıklar olabileceği gibi hizmetler, lisanslar, sunucular ve çok daha fazlası olabilir. Özellikle modelleme yazılımı bağımlılıkları söz konusu olduğunda, zaman içinde iki değişim formatı ortaya çıkmıştır: CycloneDX ve SPDX. Her ikisi de olası bağımlılıklar da dahil olmak üzere farklı yazılım bileşenlerinin tanımlanmasına izin verir:
Ancak betimleyici dil yeterli değildir. Bunun yerine, belirli ortam da tanımlanmalı ve güncel tutulmalıdır. Tabii ki, bu açıklamalar manuel olarak oluşturulabilir - ve bazen, örneğin harici hizmetlere bağlıyken, başka seçenek yoktur. Bununla birlikte, yazılım için açıklamalar oluşturmaya gelince, manuel çaba mantıklı değildir. Burada, bu açıklamaların oluşturulması ve sürdürülmesi, CI/CD ardışık düzeninin bir parçası olarak tamamen otomatik olarak gerçekleşmelidir. Temel olarak iki yaklaşım vardır: yapı sürecine entegrasyon ve yapı eserlerinin taranması.
CI/CD entegrasyonu – oluşturma süreci
Derleme işlemi sırasında SBOM oluşturma (Resim: Trend Micro).
Hem CycloneDX hem de SPDX, doğrudan oluşturma sürecine entegre edilebilecek araçlara sahiptir. Bunlar doğrudan "kaynağında" (geçici) bağımlılıkları çıkarır. Bunlar kitaplıklar, yürütülebilir dosyalar, aynı zamanda kapsayıcılar veya kap katmanları olabilir. Doğrudan entegrasyon ayrıca, örneğin yalnızca oluşturma sırasında var olan, ancak bitmiş üründe olmayan bağımlılıkları izlemeyi mümkün kılar.
CI/CD entegrasyonu – yapay yapı oluşturun
Derleme sürecine doğrudan müdahale etmenize izin verilmese bile, CycloneDX ve SPDX için nihai sonucu "sonradan" tarayan araçlar vardır. Bu, bu araçların, örneğin Java uygulamasından bağımlılıkları çıkardığı ve bunları belgelediği anlamına gelir. Bu araçlar her zaman yalnızca nihai sonucu gördüğünden, artık nihai sonuçtan çıkarsanamayacakları için bazı bağımlılıkların basitçe gözden kaçması oldukça olasıdır.
Güvenlik Açığı İzleme
Derleme işleminden sonra SBOM oluşturma (Resim: Trend Micro).
Yalnızca güvenlik açığı izleme ile ilgilenen şirketler için bu araçların çoğu güvenlik açığı veritabanlarıyla doğrudan korelasyon da sunar. Bu, çıktının yalnızca bulunan bileşenleri değil, aynı zamanda güvenlik açıklarının bir listesini de içerdiği anlamına gelir. Bu, örneğin snyk, Trend Micro Application Security veya Trend Micro Container Security'nin CI/CD boru hattına entegrasyonu ile karşılaştırılabilir.
OWASP Bağımlılık İzleme
Lisansların, envanterin veya dağıtım derecesinin izlenmesi ve belgelenmesi de bir rol oynuyorsa, başka çözümler (ek olarak) mevcuttur. Bu ortamda, OWASP'nin (Açık Web Uygulaması Güvenlik Projesi) bağımlılık izleme aracı kesinlikle en iyi köpeklerden biridir. Açık kaynaklı bir çözüm olarak, genellikle CI/CD ardışık düzenlerine entegre edilir ve CycloneDX/SPDX verileri (manuel, API) aracılığıyla veya doğrudan oluşturma sürecinden SBOM verilerini orada alır. Ek olarak Dependency Track, çeşitli güvenlik açığı veritabanlarından güvenlik açığı verilerini otomatik olarak depolar ve (geçmiş) yapılardan ve güvenlik açıklarından gelen verileri sürekli olarak ilişkilendirir. Eşleşmeler buna göre bir panoda görüntülenir veya doğrudan sohbet ve CI/CD entegrasyonu yoluyla raporlanır veya isteğe bağlı olarak otomatik düzeltme için araçlara iletilir.
Dependency Track entegrasyonu (Resim: https://github.com/DependencyTrack/dependency-track )
Dependency Track, "Log4Shell'den nerelerden etkileniyorum" sorusunun kolayca cevaplanabileceği bir veri tabanıdır. Bu cevap, yazılımın yalnızca güncel sürümlerini içermekle kalmaz, aynı zamanda eski sürümlerin açıklamalarını da sağlar. Bu nedenle olası bir bulgu, mevcut sürümde bir şirketin etkilenmediği (yeterince yamalı olduğu için) ancak 34 eski sürümün etkilendiği olabilir. Artık kurulu sürümlerin sayısı hakkındaki bilgileri de takip ediyorsanız, bu, sağlam temelli bir risk değerlendirmesi için neredeyse mükemmel bir veridir.
Log4j, Log4Shell ve tedarik zincirleri hakkında sonuç
Son olarak, başlangıçta sorulan soruları cevaplayabilmek önemlidir: Biz (doğrudan veya yazılım tedarik zincirimizde) Log4J kullanıyor muyuz? Öyleyse, Log4Shell'den ne ölçüde (sürüm, dağıtım) etkileniyoruz? Bu soruyu yanıtlamak için gereken çaba, yazılım tedarik zinciriniz hakkında ne ölçüde bilgi sahibi olduğunuzun ve bu konuda yardımcı olacak araçları kullanmaya değip değmeyeceğinin bir göstergesidir.
Araçlarla ilgili olarak, "sadece" "etkileniyor muyum" sorusuyla ilgili olup olmadığını netleştirmek önemlidir. Bu durumda, snyk gibi araçlar veya GitHub ve GitLab'a entegre edilmiş seçenekler yardımcı olacaktır. Öte yandan, daha kapsamlı bir görünüm isteniyorsa, yazılım eserlerini yakalamak ve kataloglamak için başka çözümler de vardır. Bunlar hem ticari hem de ücretsizdir. Açık kaynak kampından Dependency Track, burada kesinlikle en yaygın olanıdır.
Bununla birlikte, nihayetinde, güvenlik açıklarının yazılım tedarik zinciri yönetimi için önemli bir argüman olduğu unutulmamalıdır - ancak kesinlikle tek argüman değildir!
TrendMicro.com'da daha fazlası
Trend Micro Hakkında Dünyanın önde gelen BT güvenliği sağlayıcılarından biri olan Trend Micro, dijital veri alışverişi için güvenli bir dünya yaratılmasına yardımcı olur. 30 yılı aşkın güvenlik uzmanlığı, küresel tehdit araştırması ve sürekli yenilikle Trend Micro işletmeler, devlet kurumları ve tüketiciler için koruma sunar. XGen™ güvenlik stratejimiz sayesinde çözümlerimiz, öncü ortamlar için optimize edilmiş nesiller arası savunma teknikleri kombinasyonundan yararlanır. Ağa bağlı tehdit bilgileri, daha iyi ve daha hızlı koruma sağlar. Bulut iş yükleri, uç noktalar, e-posta, IIoT ve ağlar için optimize edilmiş bağlantılı çözümlerimiz, daha hızlı tehdit algılama ve yanıt için tüm kuruluş genelinde merkezileştirilmiş görünürlük sağlar.