Bir yazılım malzeme listesi (SBOM), kuruluş savunucularının yazılım güvenlik açıklarının etkisini izlemek, makul yama yönetimini yönetmek ve bir bütün olarak yazılım tedarik zincirinin bütünlüğünü korumak için kullanabileceği önemli bir araçtır. Çok sayıda endüstri lideri böyle söylüyor. Amerika Birleşik Devletleri Başkanlığı Ofisi öyle söylüyor.
Peki neden henüz yaygın olarak kullanılmıyorlar? Yazılım satıcıları ne hakkında endişeleniyor? Bizim bilmediğimiz bir şey mi biliyorlar?
Yakın zamanda Londra, Whitehall’da düzenlenen bir CISO Forumunda, birçok CISO, özellikle bulut özellikli bir ortamda uygulama güvenliğindeki zorlukların ve değişim hızının kendilerini biraz şaşkına çevirdiğini ve mimari modellerini değiştirmeye ve tamamen güvenli hale gelmeyi düşünmeye zorladığını hissetti. bulut yerlisi. Özellikle, IP tabanlı erişim listeleri ve uç nokta tabanlı güvenlik kontrolleri gibi eski kontrol yöntemlerinden vazgeçme konusunda bir isteksizlik vardı.
SBOM’u Başlatmakta Tereddüt Ediyor
SBOM’lerin sağlanmasını geciktirme eğilimini tetikleyebilecek birkaç ilginç olasılık vardır.
İlk olarak kendi tedarik zincirlerinin cehaleti. Satıcıların aslında bazı yazılımlarının kökenini bilmemeleri mümkündür. Büyük geliştirme ekiplerinde ve uzun, karmaşık projelerde, kodun tüm bölümlerini etkili bir şekilde “kara kutuya” koymak yaygın bir uygulamadır.
Durum buysa, kuruluşun yazılımlarının kökenini tam olarak bilmeyebileceği gerçeği, sayısız endişeyi gündeme getirir. Kötü sürüm takibinden tüm şirketin kaderini kodlama ellerinde tutan potansiyel olarak vazgeçilmez çalışanların varlığına kadar her şeyi gösterebilir. Böyle bir şirketin ürünleri için SBOM yayınlamaktan çekinmesi tamamen anlaşılır bir durumdur.
Bir şirketin SBOM’lara karşı temkinli davranmasına neden olabilecek başka bir senaryo da ürün neredeyse tamamen başka ürünlerin montajıysa. Programların, üçüncü taraf kitaplıkları ve bileşenleriyle bir araya getirilmiş özel kodların sonucu olduğu modern yazılım geliştirmenin bir gerçeğidir. Şirket kendi kodunun çok düşük bir yüzdesini yazmışsa, o zaman SBOM esasen bir başkasının ürünü klonlaması için bir tarif kartı haline gelebilir.
Ancak olası senaryo, yazılım firmalarının artı görmüyorum, yalnızca potansiyel olumsuzluk SBOM’ları serbest bırakmak için. Şu anda, ürün hatları için SBOM’ları piyasaya sürme konusunda çok az pazar baskısı var. Dahili kullanım için bir tane oluşturmuş olabilirler, ancak onları halka açık hale getirmek için gerçek bir baskı yoktur. CISO’lar tarafından dile getirilen temel endişe, bir SBOM’nin görünürlüğü artırabilmesine rağmen, düzeltmeye yönelik çok az itici güç sağlaması ve yazılım kusurlarını düzeltme konusunda sorumluluk taşımaması ve sorunu tamamen son kullanıcının yani CISO’nun kucağına bırakmasıdır.
SBOM’u Geçmek
Endüstrinin veya satın alma halkının, her büyük oyuncuyu tüm ürünleri için bir SBOM yayınlamaya zorlamak için gereken pazar baskısını oluşturabilmesi pek olası değildir. Mayıs 2021’de ABD hükümeti icra emri çıkardı yazılım tedarik zinciri için bir kontrol önlemi olarak açıkça SBOM’lar için çağrıda bulunan ülkenin siber güvenliğini iyileştirmek. AB hükümeti kendi payına bir plan yaptı. Siber Esneklik önerisi ABD düzeninin gerekliliklerini yankılamak ve desteklemek için.
Bir SBOM’nin ana amacı yama yönetimi ve güvenlik açığı ilişkilendirmesiyse, siber güvenlik personelinin bakması gereken ikincil bir izleme ve koruma katmanı vardır: saldırı yüzeyi yönetimi (ASM).
Kurumsal güvenlik ekiplerinin kullandıkları yazılımın X, Y ve Z paketlerini içerdiğini bilmesi biraz daha kolay olsa da, uygulama güvenliğini yönetmenin tek yolu bu değildir. Bu yazılım paketlerinin güvenlik danışma geçmişini izleyerek, kurban olabilecekleri en olası saldırı vektörlerini tahmin edebiliriz.
Bir şirketin kullandığı her yazılım parçasından derlenen bu güvenlik açıklarının birleşimi, bir kuruluşun saldırı yüzeyini oluşturur. ASM’nin yapmaya çalıştığı şey, bu zayıflıkları akıllıca kategorilere ayırmak ve yeni tehditlerin keşfini, düzeltilmesini ve sürekli izlenmesini otomatik hale getirmektir.
Bu, bir güvenlik açığı danışma hizmetini bir kurumsal yazılım yönetimi çözümüyle birleştirmek gibidir. ASM’nin bunu yapma şekli üründen ürüne değişir, ancak genellikle bir miktar makine öğrenimi söz konusudur. Bu şekilde, belirli sıfır gün istismarları keşfedildiğinde, her satıcıdan ayrıntılı bir SBOM’ye sahip olmasanız bile bunların saldırı yüzeyinize uygulanma olasılığının ne olduğunu bileceğiniz şekilde tahmine dayalı modeller oluşturulabilir.
İyi bir ASM, ördeklere ördek gibi davranmanın ek yararına sahiptir. Bilirsin: Ördeğe benziyorsa ve ördek gibi vaklıyorsa, onun yerine başka birinin onu kuğu olarak etiketlemesi önemli değil. ASM yalnızca sonuçları önemser. Bir şirket Open Dynamics Engine kullandığında ısrar ederse, ancak gizemli bir nedenle PhysX motoruyla aynı güvenlik açıklarının kurbanı olursa, ASM etiketleri tamamen yok sayar ve duruma uyan düzeltmeleri değil, duruma gerçekten uyan düzeltmeleri önerir. isimlere
SBOM’un yaygın olarak benimsenmesine yönelik hareket yavaş olmaya devam etse bile, güvenlik profesyonellerinin ASM ile güçlü bir alternatifi var. ASM’nin herhangi bir SBOM tabanlı yazılım yönetişimini dinamik bir risk azaltma sistemi ile tamamlayacağını da belirtmekte fayda var.
Güvenlik açığı bulma ve izleme ihtiyaçlarınızı karşılamak için yerel olarak bir şey benimsemek ve dağıtmak yerine, başka bir alternatif de genişletilmiş varlık saldırı yüzeylerini izleyebilen aracısız bir güvenlik modelini benimsemektir. Örneğin, cihaz zekası firması Armis, bunu tamamen bulutta yerel bir yaklaşımla yapıyor. Bunu IoT cihazlarını, bulut örneklerini ve uç ağ kurulumlarının yanı sıra geleneksel şirket içi kurulumları kapsayan bir ASM çözümü olarak düşünün.
Böyle bir model, büyük kurumsal operasyonlar için daha çekici olabilecek varlık istihbaratına farklı, daha küresel bir bakış açısı sunar. Bununla birlikte, daha küçük operasyonlar muhtemelen paralarını iyi bir ASM için biriktirmek ve genişletilmiş ağ cihazları için ekstra ihtiyatlı olmak isteyeceklerdir.
