(Yorum) boşluğuna dikkat edin: Tehdit modellemenin önemli olmasının bir başka nedeni

[ This article was originally published here ]

Bu yazının içeriği tamamen yazarın sorumluluğundadır. AT&T, yazar tarafından bu makalede sağlanan görüşlerin, konumların veya bilgilerin hiçbirini benimsemez veya desteklemez.

Güvenlik açıkları, güvenlik standartlarına ve yönergelerine göre nereye uyuyor? Bir kapsam sorunu muydu yoksa bir yorumlama ve uygulama sorunu muydu? Bir ürün, ortam, kuruluş veya iş sektörü, standart gereklilikleri açısından en çok nerede başarısız oluyor? Bu sorular genellikle bir yanda standartlar ya da yönetmelikler ile diğer yanda gereksinimlerin yorumlanması ve uygulanması arasındaki boşluk nedeniyle cevapsız bırakılmaktadır. Sertifikalı ürünler ve ortamlar, genellikle standardın gereklilikleri tarafından kapsanması gereken güvenlik sorunlarından muzdariptir.

İçinde [1]örneğin yazarlar, IEC 62443 sertifikalı hassas ürünlere örnekler veriyor. İçinde [2], SANS, PCI sertifikalı şirketlerin durumunu ve neden hala ihlal edildiğini tartışıyor. Gereksinimlerin uygulanmasında veya değerlendirme sürecinde ortaya çıkan bu “yorumlama boşluğu”, güvenliği engeller ve uyumlu olmanın güvenli olmakla aynı şey olmadığı gerçeğine yol açar.

Genel olarak tanımlayıcı bir yaklaşıma sahip olan standartlardaki kılavuzların ve gerekliliklerin yorumlanması kuşkusuz kolay bir iş değildir. Gereksinimler bağlama, kaynaklara, mevcut tehdit ortamına, altta yatan teknolojilere vb. bağlı olarak oldukça genel ve yoruma açık olabilir. Belirli gereksinimler, paydaş türüne bağlı olarak, uygulama tarafını kaçınılmaz olarak etkileyecek olan çelişkili yorumlara da yol açabilir. .

Tehdit modelleme, standartların ve kuruluşun kendi güvenlik politikalarının uygulanmasındaki eksikliklerden (hatta olası kısayollardan) kaçınmanın bir yoludur. Tehdit modellemeyi, gereksinimlerin uygun şekilde uygulanması için bir uygulama mekanizması olarak düşünün. Bunun böyle olmasının nedeni basit; Tehdit modelleme, gereksinimleri sisteme yönelik ilgili tehditler açısından düşünür ve ilişkili riskleri azaltmak veya tamamen önlemek için azaltmaları belirler. Sonuç olarak, her gereksinim, belirli koşullar veya bağlam altındaki ilgili kullanım durumlarını kapsayan bir dizi tehdit ve hafifletme ile eşlenir; örneğin, güven sınırları nelerdir, kullanılan veya değerlendirilen protokoller ve teknolojiler, üçüncü taraf etkileşimleri, veri akışları, veri depolama, vesaire.

Teknik gereksinimler söz konusu olduğunda, şirketler aleyhine denetlenmiş olsa bile yorumlanma endişesi devam ettiğinden, bu günümüzde bir zorunluluk haline geliyor. Aşağıda sunulan veri analizi, Endüstriyel Kontrol Sistemlerinde (ICS) açıklanan güvenlik açıkları ile bu alandaki standartların ‘altın standardında’, yani IEC 62443’te bildirilen teknik gereklilikler arasında bağlantı kurar. geniş anlamda gereksinimler ve daha spesifik bağlam ve süreçlere duyulan ihtiyaç.

CISA ICS tavsiyelerinin haritalanması

2010 ile 2023 ortası arasında yayımlanan 2,5 bine yakın öneriyi temsil eden CISA ICS danışma belgesi verilerinin analizi [3], bir uygulayıcının veya değerlendiricinin karşılaştığı zorluğun boyutunu ortaya koymaktadır. Tablo 1, en önemli zayıflıkları ve ilgili öneri sayısını ve ayrıca IEC 62443 gereksinimlerinin eşlemesini sunar. Etkilenen sektörler, CVSS önem dağılımı ve sektör başına en önemli zayıflıklar da rapor edilir; Şekil 1 ve 2 ve Tablo 2’de.

Tablo 1. CISA’nın ICS tavsiyelerindeki ve bunların IEC 62443 eşlemesindeki en önemli zayıflıklar.

Tablo 2. Sektör başına en önemli zayıflıklar.

Kılavuz gereksinimlerin yorumu

Tablo 1, güvenlik açıklarının eşlendiği çeşitli soyutlama düzeylerini göstermektedir. Bu, gereksinimlerin yorumlanmasıyla ilişkili artan karmaşıklığa yol açan ana sorunlardan biridir; hem uygulama hem de değerlendirme için Yüksek düzeyde ayrıntı düzeyi, gerekli güvenlik mekanizmalarının tanımlanmasına izin verirken, yorumlama ve uygulama sırasında düşük düzeyde ayrıntı düzeyi, belirli bir sistemin maruz kalabileceği tüm tehdit veya arıza türlerinin daha iyi anlaşılmasına izin verdiği için gereklidir. ör. bir konuşlandırma modeli veya altta yatan bir teknoloji verildiğinde.

Tablo 1’deki ilk yirmi zayıflıktan on birinin altına düştüğü “Girdi doğrulama” gerekliliği durumu açıklayıcıdır. Yüzeyde, giriş doğrulaması oldukça basittir; girdileri analiz edin ve uygunsuz olarak değerlendirilebilecek hiçbir şeye izin vermeyin. Ancak pratikte, potansiyel olarak doğrulamak için verilerin ve girdi kullanım durumlarının özelliklerinin sayısı göz korkutucu olabilir. Tüm olası köşe durumlarını temizlemek de zor, hatta imkansız olabilir. IEC 62443 “giriş doğrulama” gereksinimi oldukça geneldir ve iki CWE kategorisini kapsar; “Girişleri Doğrula” [4] ve “Bellek Arabelleği Hataları” [5]. Bu durumda, her gereksinim kapsamındaki ilgili tehditleri tanımlayabilmek ve bunların nasıl önlenebileceğini, yani söz konusu gereksinime ulaşılabileceğini belirlemek için hedef uygulama veya sistem hakkında net bir anlayışa sahip olmak çok önemlidir.

Öte yandan, “Uygunsuz erişim kontrolü” zayıflığı [6] aynı zamanda ilginç bir kullanım durumudur. Son derece yüksek düzeydedir ve IEC 62443’ün iki temel gereksinimiyle eşleşir. Bu, açıklama raporlarında yüksek düzey soyutlama zayıflıklarının kötüye kullanıldığı güvenlik açığı raporlarındaki bir sorunu vurgular. İlgili erişim denetimi türüyle ilgili daha spesifik zayıflıklar daha uygun olurdu, örneğin eksik veya zayıf kimlik doğrulama, eksik veya yanlış yetkilendirme vb. Bu, özellikle gerçek dünyadaki güvenlik açıklarının teknik gereksinimlerle nasıl ilişkili olduğu konusunda trend analizi için kullanışlı değildir. standartlarda ve yönetmeliklerde.

Tehdit modelleme her iki durumda da faydalıdır. Yazılım geliştiricileri, sistem mimarları ve güvenlik uzmanları, uygulama veya sistem kurulumuyla ilgili belirli varsayımlar verildiğinde gereksinimleri anlayabilir ve bu gereksinimler kapsamındaki öngörülebilir güvenlik sorunlarını ele alabilir. Ayrıca mevcut tehdit modelleme araçları, tehdit istihbaratı verilerine dayalı olanlar da dahil olmak üzere ilgili tehditleri ve bunların etkilerini otomatik olarak oluşturarak süreci hızlandırabilir. Etki azaltma seti, farklı ihtiyaçları karşılayacak şekilde de uyarlanabilir; örneğin, dört güvenlik seviyesinin tanımlandığı IEC 62443 standardında olduğu gibi potansiyel bir rakibin gücü. Bu güvenlik seviyeleri (1 ila 4), farklı risk seviyelerine karşı koymak için teknik gereklilikleri ve gereklilik geliştirmelerini tanımlar.

Tehdit modellemeyi bir çerçeve olarak kullanarak, gereksinimlerin yorumlanması ve uygulama ve devreye alma önlemleriyle eşleştirilmesinin daha öngörülebilir hale geldiğine inanıyorum. Ayrıca geliştiricilere ve sistem mimarlarına, hedef sistem bağlamı, bağımlılıkları ve mevcut tehdit ortamı göz önüne alındığında, gereksinimlerin ne olması gerektiğine dair daha eksiksiz bir kapsam ve doğru açıklama şansı verecektir.

Bu blogun konuk yazarı, iriusrisk.com’da bir güvenlik araştırmacısıdır.

Referanslar

[1] https://arxiv.org/pdf/2303.12340.pdf

[2] https://www.sans.org/white-papers/36497/

[3] https://www.cisa.gov/news-events/cybersecurity-advisories

[4] https://cwe.mitre.org/data/definitions/1019.html

[5] https://cwe.mitre.org/data/definitions/1218.html

[6] https://cwe.mitre.org/data/definitions/284.html

reklam