[ 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.
|
zayıflık |
İsim |
Danışman sayısı |
IEC 62443 teknik gerekliliği |
|
CWE-20 |
Hatalı Giriş Doğrulaması |
266 |
SR/CR 3.5 – Giriş doğrulama |
|
CWE-121 |
Yığın Tabanlı Arabellek Taşması |
257 |
|
|
CWE-79 |
Web Sayfası Oluşturma Sırasında Girdinin Uygun Olmayan Nötrleştirilmesi (“Siteler Arası Komut Dosyası Çalıştırma”) |
205 |
|
|
CWE-119 |
Bir Bellek Arabelleğinin Sınırları İçerisindeki İşlemlerin Uygun Olmayan Kısıtlaması |
185 |
|
|
CWE-284 |
Uygunsuz Erişim Kontrolü |
159 |
FR1 – Tanımlama ve doğrulama kontrolü (IAC) FR2 – Kontrolü kullan (UC) |
|
CWE-125 |
Sınır dışı Okuma |
158 |
SR/CR 3.5 – Giriş doğrulama |
|
CWE-22 |
Bir Yol Adını Kısıtlanmış Bir Dizinle Uygun Olmayan Bir Şekilde Sınırlandırma (“Yol Geçişi”) |
149 |
|
|
CWE-400 |
Kontrolsüz Kaynak Tüketimi |
145 |
SR/CR 7.1 – Hizmet reddi koruması SR/CR 7.2 – Kaynak yönetimi |
|
CWE-787 |
Sınır Dışı Yazma |
139 |
SR/CR 3.5 – Giriş doğrulama |
|
CWE-287 |
Yanlış Kimlik Doğrulama |
137 |
SR/CR 1.1 – İnsan kullanıcı tanımlama ve doğrulama SR/CR 1.2 – Yazılım süreci ve cihaz tanımlama ve doğrulama |
|
CWE-122 |
Yığın Tabanlı Arabellek Taşması |
128 |
SR/CR 3.5 – Giriş doğrulama |
|
CWE-200 |
Hassas Bilgilerin Yetkisiz Bir Kişiye Açıklanması |
115 |
FR4 – Veri gizliliği (DC) SR/CR 3.7 – Hata işleme |
|
CWE-798 |
Sabit Kodlanmış Kimlik Bilgilerinin Kullanımı |
101 |
SR/CR 1.5 – Doğrulayıcı yönetimi |
|
CWE-306 |
Kritik İşlev için Eksik Kimlik Doğrulaması |
98 |
SR/CR 1.1 – İnsan kullanıcı tanımlama ve doğrulama SR/CR 1.2 – Yazılım süreci ve cihaz tanımlama ve doğrulama SR/CR 2.1 – Yetkilendirme uygulaması |
|
CWE-352 |
Siteler Arası İstek Sahteciliği (CSRF) |
84 |
SR/CR 1.4 – Tanımlayıcı yönetimi |
|
CWE-89 |
Bir SQL Komutunda Kullanılan Özel Öğelerin Uygun Olmayan Nötrleştirilmesi (“SQL Enjeksiyonu”) |
81 |
SR/CR 3.5 – Giriş doğrulama |
|
CWE-319 |
Hassas Bilgilerin Açık Metin İletimi |
75 |
SR/CR 4.1 – Bilgi gizliliği |
|
CWE-427 |
Kontrolsüz Arama Yolu Elemanı |
64 |
SR/CR 3.5 – Giriş doğrulama CR 3.4 – Yazılım ve bilgi bütünlüğü |
|
CWE-120 |
Girdi Boyutunu Kontrol Etmeden Tampon Kopyası (‘Klasik Tampon Taşması’) |
62 |
SR/CR 3.5 – Giriş doğrulama |
|
CWE-522 |
Yetersiz Korunan Kimlik Bilgileri |
62 |
SR/CR 1.5 – Doğrulayıcı yönetimi |
|
Şekil 1. Sektör başına güvenlik açığı sayısı
|
|
Şekil 2. CVSS şiddet dağılımı.
|
Tablo 2. Sektör başına en önemli zayıflıklar.
|
sektör |
En Zayıf Nokta |
İsim |
Danışman sayısı |
|
Kritik Üretim |
CWE-121 |
Yığın Tabanlı Arabellek Taşması |
175 |
|
Enerji |
CWE-20 |
Hatalı Giriş Doğrulaması |
147 |
|
Su ve Atıksu |
CWE-20 |
Hatalı Giriş Doğrulaması |
87 |
|
Ticari Tesisler |
CWE-79 |
Web Sayfası Oluşturma Sırasında Girdinin Uygun Olmayan Nötrleştirilmesi (“Siteler Arası Komut Dosyası Çalıştırma”) |
42 |
|
Gıda ve Tarım |
CWE-20 |
Hatalı Giriş Doğrulaması |
55 |
|
Kimyasal |
CWE-20 |
Hatalı Giriş Doğrulaması |
54 |
|
Sağlık ve Halk Sağlığı |
CWE-284 |
Uygunsuz Erişim Kontrolü |
32 |
|
Toplu taşıma |
CWE-121 |
Yığın Tabanlı Arabellek Taşması |
31 |
|
Yağ ve gaz |
CWE-119 |
Bir Bellek Arabelleğinin Sınırları İçerisindeki İşlemlerin Uygun Olmayan Kısıtlaması |
18 |
|
Devlet Tesisleri |
CWE-121 |
Yığın Tabanlı Arabellek Taşması |
18 |
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