Niteliksel vs Niceliksel: Değişim Zamanı Üçüncü Taraf Güvenlik Açıklarının Ciddiyetini Nasıl Değerlendiriyoruz?

Yazar: Roger Morrison
Yaratılış Tarihi: 26 Eylül 2021
Güncelleme Tarihi: 20 Haziran 2024
Anonim
Niteliksel vs Niceliksel: Değişim Zamanı Üçüncü Taraf Güvenlik Açıklarının Ciddiyetini Nasıl Değerlendiriyoruz? - Teknoloji
Niteliksel vs Niceliksel: Değişim Zamanı Üçüncü Taraf Güvenlik Açıklarının Ciddiyetini Nasıl Değerlendiriyoruz? - Teknoloji

İçerik


Kaynak: BrianAJackson / iStockphoto

Paket servisi:

Açık kaynak kodlu bileşenler için riski değerlendirmeyi düşündüğümüz şeyleri bir kenara bırakmanın zamanı geldi.

Yazılım geliştirme topluluğunun güvenlik açıklarını ne kadar ciddiye alması gerektiğini değerlendirmek için bir sistem geliştirmek, bunu hafifletmek için bir zorluktur. Kod insanlar tarafından yazılmıştır ve daima kusurları olacaktır. Öyleyse sorun, hiçbir şeyin mükemmel olmayacağını varsayarsak, bileşenleri üretkenlikle çalışmaya devam etmemizi sağlayacak şekilde risklerine göre en iyi şekilde nasıl sınıflandırırız?

Sadece gerçekler

Her biri kendi geçerli gerekçesine sahip, bu problemin üstesinden gelebilecek birçok farklı yaklaşım olsa da, en yaygın yöntem kantitatif bir modele dayanıyor gibi görünmektedir.

Bir yandan, bir güvenlik açığının ciddiyetine karar vermek için nicel bir yaklaşım kullanmak, yalnızca güvenlik açığıyla ilgili faktörlere bağlı olarak daha objektif ve ölçülebilir olduğu için faydalı olabilir.


Bu metodoloji, yazılım endüstrisinde bileşen, kütüphane veya projenin ne kadar yaygın şekilde kullanıldığı ve bir saldırgana ne tür bir erişim sağlayabileceği gibi faktörler göz önüne alındığında, güvenlik açığından yararlanılması durumunda ne tür bir zararın olabileceğine bakar enkaz, hedeflerini ihlal etmek için kullanmalılar. Potansiyel sömürü kolaylığı gibi faktörler, skoru etkilemede büyük rol oynayabilir. (Güvenlik hakkında daha fazla bilgi için, Siber Güvenlik: Yeni Gelişmeler Yeni Tehditler Nasıl Sağlıyor - Ve Genel Müdür Yardımcılığı'na bakın.)

Makro bir seviyeye bakmak istiyorsak, niceliksel bakış açısı, bir kırılganlığın sürüye nasıl zarar verebileceğine bakar, saldırıya maruz kalabilecek şirketlere düşebilecek hasara daha az odaklanır.

Ulusal Güvenlik Açığı Veri Tabanı (NVD), belki de en iyi bilinen güvenlik açığı veri tabanı, bu yaklaşımı hem 2 hem de 3 sürümlerinde Ortak Güvenlik Açığı Puanlama Sistemi (CVSS) için kullanıyor. Güvenlik açıklarını değerlendirme konusundaki metriklerini açıklayan sayfalarında, yöntemlerini şöyle yazarlar:


Kantitatif modeli, kullanıcıların puanları oluşturmak için kullanılan temel güvenlik açığı özelliklerini görmelerini sağlarken, tekrarlanabilir doğru ölçümler sağlar. Bu nedenle, CVSS, doğru ve tutarlı bir kırılganlık etki puanları gerektiren sektörler, kuruluşlar ve hükümetler için standart bir ölçüm sistemi olarak çok uygundur.

Oyundaki nicel faktörlere dayanarak, NVD daha sonra, her ikisi de 1 - 10 arasında, 10'u en ağır olmakla birlikte - aynı zamanda LOW, MEDIUM ve HIGH kategorilerinde bir sayı ile, bir ciddiyet skoru yakalayabilir. .

Hata Yok, Stres Yok - Hayatınızı Yok Etmeden Hayat Değiştiren Yazılım Yaratma Adım Adım Kılavuzunuz

Hiç kimse yazılım kalitesiyle ilgilenmediğinde programlama becerilerinizi geliştiremezsiniz.

Etki Muhasebesi?

Bununla birlikte, NVD, belirli bir istismarın zarar vermesine ne kadar etkili olduğuna dayanarak, daha hassas bir ölçüt olarak nitel bir önlem olarak adlandırabileceğimiz şeylerden uzak durmaya çalışıyor gibi görünüyor. Adil olmak gerekirse, güvenlik açığının sistem üzerindeki etkisini ölçerek, gizlilik, bütünlük ve kullanılabilirlik faktörlerine bakarak etkilerini birleştiriyorlar. Bunların hepsi, daha kolay ölçülebilir erişim vektörü, erişim karmaşıklığı ve kimlik doğrulama gibi, göz önünde bulundurulması gereken önemli unsurlardır, ancak bir güvenlik açığı bir kuruluşun gerçek zararlara neden olduğu zaman, gerçek dünyadaki etkiyi ilişkilendirme görevini görmezler.

Örneğin, ehliyet bilgileri, sosyal güvenlik numaraları ve talihsiz sahtekarlık operasyonları gerçekleştirmek için vicdansız karakterler tarafından kullanılabilecek diğer parçalar da dahil olmak üzere, 145 milyon insanın kişisel olarak tanımlanabilir bilgilerini açığa vuran Equifax ihlallerini ele alalım.

Apache Struts 2 projesinde Equifax'ın web uygulamasında kullandığı ve saldırganların ön kapıdan içeri girmesini ve sonunda kollarını sulu kişisel bilgilerle dolu hale getirmelerini sağlayan güvenlik açığı (CVE-2017-5638) oldu. .

NVD hak olarak 10 ve HIGH şiddetli bir puan verirken, kararları potansiyel zararlarını kantitatif olarak değerlendirmelerinden kaynaklandı ve Equifax ihlali halka açık hale geldiğinde meydana gelen kapsamlı hasardan etkilenmedi.

Bu NVD’nin gözetimi değil, politikalarının bir parçası.

NVD, her güvenlik açığının doğuştan gelen özelliklerini temsil eden CVSS "temel puanları" sağlar. Şu anda "geçici puanlar" (güvenlik açığı dışındaki olaylar nedeniyle zaman içinde değişen metrikler) veya "çevresel puanlar" (güvenlik açığının kuruluşunuz üzerindeki etkisini yansıtacak şekilde özelleştirilmiş puanlar) sunmuyoruz.

Karar vericiler için, niceliksel ölçüm sistemi, sektöre zarar verme ihtimaline baktığından daha az önemli olmalıdır. Bir bankanın STK'sıysanız, bir müşterinin verilerini kullanmak veya paralarını daha da kötüleştirmek için kullanılırsa, bir istismarın yapabileceği nitel etkiyle ilgilenmelisiniz. (Tech'deki En Korkunç 5 Tehdit'teki farklı güvenlik açıkları hakkında bilgi edinin.)

Sistemi Değiştirme Zamanı?

Öyleyse Equifax davasında kullanılan Apache Strusts 2'deki güvenlik açığı, hasarın ne kadar yaygın olduğu veya NVD gibi bir sistem için çok subjektif olduğu ortaya çıkacak mıydı? devam etmek?

NVD tarafından açıklandığı gibi "çevresel puan" veya "geçici puan" bulmak için gerekli verileri bulmak, ücretsiz CVSS ekibinin yöneticilerini bitmeyen bir eleştiriye ve bir ton çalışmaya kadar açarak çok zor olacağını kabul ediyoruz. NVD ve diğerleri için yeni bilgiler ortaya çıktıkça veritabanlarını güncelledikleri için.

Elbette, böyle bir puanın nasıl derleneceği ile ilgili bir soru var, çünkü çok az sayıda kuruluş, açıklama yasası gerektirmedikçe bir ihlalin etkisi hakkında gerekli verileri sunması muhtemeldir. Uber örneğinden, şirketlerin bir kamuoyunda karışıklığa maruz kalmaları halinde bir ihlalle ilgili bilgilerin basına ulaşmasını engellemek umuduyla hızlı bir şekilde ödeme yapmak istediklerini gördük.

Belki de gerekli olan, güvenlik açığı veritabanlarındaki iyi çabaları içerebilen ve bilgi mevcut olduğunda kendi ek puanlarını ekleyebilecek yeni bir sistemdir.

Birincisi tüm bu yıllar boyunca işini yeterince iyi yapmış gibi göründüğünde neden bu ekstra puanlama katmanını başlattın?

Açıkçası, kuruluşların başvurularının sorumluluğunu üstlenmeleri sorumludur. İdeal bir dünyada, herkes envanterine eklemeden önce ürünlerinde kullandıkları bileşenlerin puanlarını kontrol eder, daha önce güvenli olduğu düşünülen projelerde yeni güvenlik açıkları keşfedildiğinde uyarılar alır ve gerekli yamaları kendi başına uygular .

Belki de bu güvenlik açıklarından bazılarının bir kuruluş için ne kadar yıkıcı olabileceğini gösteren bir liste varsa, o zaman kuruluşlar riskli bileşenlere yakalanmamak için daha fazla baskı hissedebilir. En azından, açık kaynak kütüphaneleri olan gerçek bir envanter alma adımlarını atabilirler.

Equifax fiyaskolarının ardından, ürünlerinde Strut’ların savunmasız sürümüne sahip olmadıklarından emin olmak için birden fazla C düzeyinden sorumlu yönetici mücadele ediyordu. Sanayiyi, açık kaynak güvenliğini ciddiye almaya itmek, bu büyüklükte bir olayın yaşanması talihsiz bir durumdur.

Umarım, uygulamalarınızın açık kaynaklı bileşenlerindeki güvenlik açıklarının, gerçek dünyadaki sonuçların çok ciddi olabileceği dersinin, karar vericilerin güvenliğini öncelikli hale getirme, ürünlerini ve müşterilerini güvende tutmak için doğru araçları seçmelerinde bir etkisi olacaktır.