Sürücüler için tehdit modelleme

Sürücü yazarları ve mimarları, tehdit modellemesini herhangi bir sürücü için tasarım sürecinin ayrılmaz bir parçası haline getirmelidir. Bu konu, Windows sürücüleri için tehdit modelleri oluşturmaya yönelik yönergeler sağlar.

Güvenlik, herhangi bir sürücü için temel bir tasarım noktası olmalıdır. Başarılı ürünler bir hedeftir. Windows için bir sürücü yazıyorsanız, bir süre, bir yerde, birinin sistem güvenliğini tehlikeye atmak için sürücünüzü kullanmayı deneyeceğini varsaymalısınız.

Güvenli bir sürücü tasarlamak şunları içerir:

• Sürücünün bir saldırıya karşı savunmasız olabileceği noktaları belirleme.
• Her bir böyle noktada gerçekleştirilebilecek saldırı türlerini analiz etme.
• Sürücünün bu tür saldırıları engelleyebilecek şekilde tasarlandığından emin olmak.

Tehdit modelleme, bu önemli tasarım görevlerine yönelik yapılandırılmış bir yaklaşımdır. Tehdit modeli, bir varlığa yönelik tehditleri kategorilere ayırmanın ve analiz etmenin bir yoludur. Sürücü yazarı açısından bakıldığında, varlıklar bilgisayar veya ağdaki donanım, yazılım ve verilerdir.

Tehdit modeli aşağıdaki soruları yanıtlar:

• Hangi varlıkların korunması gerekir?
• Varlıklar hangi tehditlere karşı savunmasızdır?
• Tehditlerin her biri ne kadar önemli veya büyük olasılıkla?
• Tehditleri nasıl azaltabilirsiniz?

Tehdit modeli oluşturma, yazılım tasarımının önemli bir parçasıdır çünkü güvenliğin ürün tasarımına entegre edilmesini sağlar, sonradan düşünülen bir konu olarak ele alınmasının önüne geçer. İyi bir tehdit modeli, tasarım süreci sırasında hataları bulup önlemeye yardımcı olabilir, böylece daha sonra olası maliyetli düzeltme eklerini ve kuruluşunuzda olası itibar zararlarını ortadan kaldırır.

Bu bölüm, sürücü tasarımına tehdit modelleme ilkelerini uygular ve bir sürücünün duyarlı olabileceği tehditlere örnekler sağlar. Yazılım tasarımı için tehdit modellemesinin daha eksiksiz bir açıklaması için bu kaynaklara bakın.

• Microsoft SDL Web sitesi:

  https://www.microsoft.com/sdl

• Microsoft SDL'nin Basitleştirilmiş Uygulaması:

  Teknik İncelemeyi İndir

• Bu blog girdisi, Michael Howard ve Steve Lipner tarafından oluşturulan The Security Development Lifecycle: SDL'nin ücretsiz bir kopyasını nasıl indirebileceğinizi açıklar:

  https://blogs.msdn.microsoft.com/microsoft_press/2016/04/19/free-ebook-the-security-development-lifecycle/

Sürücüler için tehdit modelleri oluşturma

Tehdit modeli oluşturmak için sürücünün tasarımının, sürücünün maruz kalabileceği tehdit türlerinin ve belirli bir tehditden yararlanan bir güvenlik saldırısının sonuçlarının kapsamlı bir şekilde anlaşılması gerekir. Bir sürücü için tehdit modelini oluşturduktan sonra olası tehditleri nasıl azaltabileceğinizi belirleyebilirsiniz.

Tehdit modellemesi, kodlama sırasında olağanüstü bir şekilde değil, sürücü tasarımı sırasında düzenli, yapılandırılmış bir şekilde gerçekleştirildiğinde en etkili yöntemdir. Yapılandırılmış bir yaklaşım, tasarımdaki güvenlik açıklarını keşfetme olasılığınızı artırarak modelin kapsamlı olduğundan emin olmanıza yardımcı olur.

Tehdit modelleme çalışmalarını düzenlemenin bir yolu şu adımları izlemektir:

1. Sürücüdeki veri akışını gösteren yapılandırılmış bir diyagram oluşturun. Sürücünün gerçekleştirdiği tüm olası görevleri ve sürücüden gelen tüm giriş ve çıkışların kaynağını ve hedefini ekleyin. Resmi veri akışı diyagramı veya benzer bir yapılandırılmış diyagram, sürücünüz aracılığıyla veri yolunu çözümlemenize ve sürücünün dış arabirimlerini, sınırlarını ve etkileşimlerini belirlemenize yardımcı olabilir.
2. Veri akışı diyagramına göre olası güvenlik tehditlerini analiz edin.
3. Önceki adımda tanımladığınız tehditleri değerlendirin ve bunların nasıl azaltıldığını belirleyin.

Veri akışı diyagramı oluşturma

Veri akışı diyagramı, genellikle işletim sistemi, kullanıcı işlemi ve cihaz olmak üzere sürücü ile etkileşimde bulunduğu dış varlıklar arasındaki veri akışını kavramsal olarak gösterir. Resmi veri akışı diyagramı aşağıdaki simgeleri kullanır:

Aşağıdaki şekilde, kuramsal çekirdek modu Windows Sürücü Modeli (WDM) sürücüsü için örnek veri akışı diyagramı gösterilmektedir. Belirli sürücü türünüzün mimarisinden bağımsız olarak kavramsal model aynıdır: tüm veri yollarını gösterin ve sürücüye giren veya sürücüden çıkan her veri kaynağını tanımlayın.

Not: Önceki şekil, bir kullanıcı işlemi ile sürücü arasında doğrudan akan verileri gösterir ve ara sürücüleri hariç tutar. Ancak gerçekte tüm istekler G/Ç yöneticisinden geçer ve belirli bir sürücüye ulaşmadan önce bir veya daha fazla üst düzey sürücüden geçiş yapabilir. Şekilde, verilerin özgün kaynağının önemini ve verileri sağlayan iş parçacığının bağlamını vurgulamak için bu ara adımlar hariç tutulmuştur. Çekirdek modu sürücüleri, kullanıcı modundan kaynaklanan verileri doğrulamalıdır.

İşletim sisteminden gelen istekler, bir kullanıcı işleminden gelen istekler veya cihazdan gelen istekler (genellikle kesintiler) nedeniyle bilgi sürücüye girer.

Önceki şekildeki sürücü, çeşitli istek türlerinde işletim sisteminden veri alır:

• DriverEntry, DriverUnload ve AddDevice yordamlarına yapılan çağrılar aracılığıyla sürücü ve cihazı için yönetim görevlerini gerçekleştirme istekleri
• Tak Çalıştır istekleri (IRP_MJ_PNP)
• Güç yönetimi istekleri (IRP_MJ_POWER)
• İç cihaz G/Ç denetim istekleri (IRP_MJ_INTERNAL_DEVICE_CONTROL)

Bu isteklere yanıt olarak, veri sürücüden işletim sistemine durum bilgisi olarak geri akar. Şekildeki sürücü, aşağıdaki istek türlerinde bir kullanıcı işleminden veri alır:

• İstek oluşturma, okuma ve yazma (IRP_MJ_CREATE, IRP_MJ_READ veya IRP_MJ_WRITE)
• Genel cihaz G/Ç denetim istekleri (IRP_MJ_DEVICE_ CONTROL)

Bu isteklere yanıt olarak çıkış verileri ve durum bilgileri sürücüden kullanıcı işlemine geri döner.

Son olarak, cihaz G/Ç işlemleri veya cihaz durumunu değiştiren kullanıcı eylemleri (tepsiyi CD sürücüsünde açmak gibi) nedeniyle sürücü cihazdan veri alır. Benzer şekilde, sürücüdeki veriler G/Ç işlemleri sırasında cihaza akar ve cihaz durumundaki değişiklikler.

Önceki şekilde, sürücü veri akışı geniş kavramsal düzeyde gösterilmiştir. Her daire görece büyük bir görevi temsil eder ve ayrıntı içermez. Bazı durumlarda, örnek gibi tek düzeyli bir diyagram veri kaynaklarını ve yolları anlamak için yeterlidir. Sürücünüz farklı kaynaklardan gelen birçok farklı türde G/Ç isteğini işleyecekse, daha fazla ayrıntı gösteren bir veya daha fazla ek diyagram oluşturmanız gerekebilir. Örneğin, "G/Ç İsteklerini İşle" etiketli daire, aşağıdaki şekilde olduğu gibi ayrı bir diyagrama genişletilebilir.

İkinci diyagramda, ilk diyagramdaki her G/Ç isteği türü için ayrı görevler gösterilir. (Kolaylık olması için, cihaza yönelik veri yolları atlanmıştır.)

Dış varlıklar ve diyagramda gösterilen giriş ve çıkış türleri, cihaz türüne bağlı olarak farklılık gösterebilir. Örneğin, Windows birçok yaygın cihaz türü için sınıf sürücüleri sağlar. Sistem tarafından sağlanan sınıf sürücüsü, genellikle bir dizi geri çağırma işlevi içeren dinamik bağlantı kitaplığı (DLL) olan satıcı tarafından sağlanan bir mini sürücü ile çalışır. Kullanıcı G/Ç istekleri sınıf sürücüsüne yönlendirilir ve daha sonra belirli görevleri gerçekleştirmek için mini sürücüdeki yordamları çağırır. Minidriver genellikle G/Ç istek paketinin tamamını giriş olarak almaz; bunun yerine, her geri çağırma yordamı yalnızca kendi görevi için gerekli olan verileri alır.

Veri akışı diyagramlarını oluştururken, sürücü istekleri için çeşitli kaynakları unutmayın. Kullanıcının bilgisayarında çalışan tüm kodlar, Microsoft Office gibi iyi bilinen uygulamalardan şüpheli olabilecek ücretsiz yazılım, shareware ve Web indirmelerine kadar bir sürücüye G/Ç isteği oluşturabilir. Cihazınıza bağlı olarak, şirketinizin cihazını desteklemek için sunduğu medya codec bileşenlerini veya üçüncü taraf filtreleri de göz önünde bulundurmanız gerekebilir. Olası veri kaynakları şunlardır:

• sürücünün işlediği IRP_MJ_XXX istekleri
• Sürücünün tanımladığı veya işlediği IOCTL'ler
• Sürücünün çağırdığını API'ler
• Geri çağırma yordamları
• Sürücünün sunduğu diğer arabirimler
• Yükleme sırasında kullanılanlar da dahil olmak üzere sürücünün okuduğu veya yazdığı dosyalar
• Sürücünün okuduğu veya yazdığı kayıt defteri anahtarları
• Yapılandırma özelliği sayfaları ve sürücünün kullandığı, kullanıcı tarafından sağlanan her türlü bilgi

Modeliniz sürücü yükleme ve güncelleştirme yordamlarını da kapsamalıdır. Sürücü yüklemesi sırasında okunan veya yazılan tüm dosyaları, dizinleri ve kayıt defteri girdilerini ekleyin. Cihaz yükleyicilerinde, ortak yükleyicilerde ve özellik sayfalarında kullanıma sunulan arabirimleri de göz önünde bulundurun.

Sürücünün dış varlıkla veri değişiminde bulunduğu herhangi bir nokta saldırılara karşı savunmasızdır.

Olası tehditleri analiz etme

Bir sürücünün güvenlik açığı olabileceği noktaları belirledikten sonra, her noktada hangi tehdit türlerinin oluşabileceğini belirleyebilirsiniz. Aşağıdaki soru türlerini göz önünde bulundurun:

• Her kaynağı korumak için hangi güvenlik mekanizmaları mevcuttur?
• Tüm geçişler ve arabirimler düzgün bir şekilde güvenli hale getirildi mi?
• Bir özelliğin uygunsuz kullanımı yanlışlıkla güvenliği tehlikeye atabilir mi?
• Bir özelliğin kötü amaçlı kullanımı güvenliği tehlikeye atabilir mi?
• Varsayılan ayarlar yeterli güvenlik sağlıyor mu?

Tehdit kategorisine STRIDE yaklaşımı

STRIDE kısaltması, yazılıma yönelik altı tehdit kategorisini açıklar. Bu kısaltma aşağıdakilerden türetilir:

• Spoofing (kimlik sahteciliği)
• Tampering
• Reddetme
• Informasyon açıklaması
• Dhizmet reddi
• Eyetki yükselmesi

STRIDE'ı kılavuz olarak kullanarak, bir sürücüyü hedefleyebilecek saldırı türleri hakkında ayrıntılı sorular oluşturabilirsiniz. Amaç, sürücüdeki her güvenlik açığı noktasında mümkün olabilecek saldırı türlerini belirlemek ve ardından olası her saldırı için bir senaryo oluşturmaktır.

• Kimlik sahtekarlık , başka bir kişinin kimlik bilgilerini kullanarak erişilemeyen varlıklara erişim elde etmektir. Bir işlem sahte veya çalınan kimlik bilgilerini geçirerek bir kimlik sahtekarlık saldırısına neden olur.

• Kurcalama, saldırı düzenlemek için verileri değiştirmektir. Örneğin, gerekli sürücü dosyaları sürücü imzalama işlemi ve erişim denetim listeleri (ACL'ler) tarafından yeterince korunmuyorsa, sürücü kurcalanmaya karşı savunmasız olabilir. Bu durumda kötü amaçlı bir kullanıcı dosyaları değiştirerek sistem güvenliğini ihlal edebilir.

• İnkar , kullanıcı bir eylemi gerçekleştirmeyi reddettiği halde eylemin hedefinin aksini kanıtlamanın bir yolu olmadığında oluşur. Bir sürücü, güvenliği tehlikeye atabilecek eylemleri günlüğe kaydetmezse, bir reddedilme tehdidine karşı savunmasız olabilir. Örneğin, video cihazının sürücüsü, cihazının odak, taranan alan, görüntü yakalama sıklığı, yakalanan görüntülerin hedef konumu gibi özelliklerini değiştirme isteklerini günlüğe kaydetmezse reddedilebilir. Sonuçta elde edilen görüntüler bozulmuş olabilir, ancak sistem yöneticilerinin soruna hangi kullanıcının neden olduğunu belirlemesi için hiçbir yol yoktur.

• Bilgilerin açığa çıkması tehditleri tam olarak adından da anlaşılacağı gibidir: bilgilerin görme izni olmayan bir kullanıcıya açıklanması. Bir kullanıcı arabelleğine veya kullanıcı arabelleğinden bilgi geçiren herhangi bir sürücü, bilgilerin açığa çıkması tehditlerine açıktır. Bilgilerin açığa çıkması tehditlerini önlemek için sürücülerin her kullanıcı arabelleğinin uzunluğunu doğrulaması ve veri yazmadan önce arabellekleri sıfır başlatması gerekir.

• Hizmet reddi saldırıları, geçerli kullanıcıların kaynaklara erişme becerisini tehdit eder. Kaynaklar disk alanı, ağ bağlantıları veya fiziksel bir cihaz olabilir. Performansı kabul edilemez düzeylere düşüren saldırılar da hizmet reddi saldırıları olarak kabul edilir. Kaynak tüketimi diğer geçerli kullanıcıların görevlerini gerçekleştirme becerisini engelliyorsa, kullanıcı işleminin bir sistem kaynağını gereksiz yere tekeline almasına olanak tanıyan bir sürücü, hizmet reddi saldırısına karşı savunmasız olabilir.

  Örneğin, bir sürücü IRQL = PASSIVE_LEVEL'de yürütülürken veri yapısını korumak için semafor kullanabilir. Ancak, sürücünün semaforu bir KeEnterCriticalRegion/KeLeaveCriticalRegion çifti içinde alması ve serbest bırakması gerekir. Bu çift, zaman uyumsuz yordam çağrılarının (APC) teslimini devre dışı bırakır ve yeniden etkinleştirir. Sürücü bu yordamları kullanamazsa, bir APC işletim sisteminin semaforu tutan iş parçacığını askıya almasına neden olabilir. Sonuç olarak, diğer işlemler (yönetici tarafından oluşturulanlar da dahil) yapıya erişemez.

• Ayrıcalıksız bir kullanıcı ayrıcalıklı durum kazanırsa ayrıcalık yükseltme saldırısı oluşabilir. Kullanıcı modu tutamacını ZwXxx yordamına geçiren çekirdek modu sürücüsü, ZwXxx yordamları güvenlik denetimlerini atladığı için ayrıcalık yükseltme saldırılarına karşı savunmasızdır. Çekirdek modu sürücüleri, kullanıcı modu çağrılarından aldıkları her tanıtıcıyı doğrulamalıdır.

  Ayrıca, bir çekirdek modu sürücüsü, G/Ç isteğinin çekirdek modundan mı yoksa kullanıcı modu çağırandan mı geldiğini belirlemek için IRP üst bilgisindeki RequestorMode değerine dayanırsa ayrıcalık yükseltme saldırıları da oluşabilir. Ağdan veya Sunucu hizmetinden (SRVSVC) gelen IRP'lerde, isteğin kaynağından bağımsız olarak RequestorMode değeri KernelMode'dur. Bu tür saldırıları önlemek için sürücülerin yalnızca RequestorMode değerini kullanmak yerine bu tür istekler için erişim denetimi denetimleri gerçekleştirmesi gerekir.

Sürücü analizi teknikleri

Analizi düzenlemenin basit bir yolu, güvenlik açığı bulunan alanları ve olası tehditleri ve her tehdit türü için bir veya daha fazla senaryoyu listelemektir.

Kapsamlı bir analiz gerçekleştirmek için, sürücüdeki güvenlik açığı olabilecek her noktada tehdit olasılığını keşfetmeniz gerekir. Her savunmasız noktada, mümkün olabilecek her tehdit kategorisini (sahtekarlık, kurcalama, reddetme, bilgilerin açığa çıkması, hizmet reddi ve ayrıcalıkların yükseltilmesi) belirleyin. Ardından, her makul tehdit için bir veya daha fazla saldırı senaryosu oluşturun.

Örneğin, önceki şekilde gösterildiği gibi IRP_MJ_DEVICE_CONTROL istekleri için veri akışını göz önünde bulundurun. Aşağıdaki tabloda, bir sürücünün bu tür istekleri işlerken karşılaşabileceği iki tür tehdit gösterilmektedir:

Güvenlik açığı olan nokta	Olası tehdit (STRIDE)	Senaryo
IRP_MJ_DEVICE_CONTROL istekleri	Hizmet reddi Yetki yükseltilmesi	Kullanıcı işlemi, cihazın başarısız olmasına neden olan bir dizi IOCTL oluşturur. Kullanıcı işlemi, FILE_ANY_ACCESS için izin veren bir IOCTL sunar.

Bir tehdit genellikle başka bir tehditle ilgilidir. Örneğin, ayrıcalıkların yükseltilmesi tehdidinden yararlanan bir saldırı, bilgilerin açığa çıkmasına veya hizmet reddine neden olabilir. Ayrıca, bazı saldırı türleri bir dizi olaya bağlıdır. Kötü amaçlı bir kullanıcı, ayrıcalıkların yükseltilmesi tehdidinden yararlanarak başlayabilir. Daha sonra, yükseltilmiş ayrıcalıkla birlikte gelen ek özelliklerle, kullanıcı ek güvenlik açıklarını bulabilir ve bu güvenlik açıklarından yararlanabilir.

Tehdit ağaçları ve ana hatları, bu tür karmaşık senaryoların modellenmesinde yararlı olabilir.

Tehdit ağacı, tehditlerin veya güvenlik açıklarının hiyerarşisini gösteren bir diyagramdır; temelde bir tehdit ağacı, kötü amaçlı kullanıcının saldırıyı bağlama adımlarını taklit eder. Saldırının nihai hedefi ağacın en üstündedir. Her alt düzey, saldırıyı gerçekleştirmek için gereken adımları gösterir. Aşağıdaki şekilde, önceki örnekteki hizmet reddi senaryosu için basit bir tehdit ağacı verilmiştir.

Tehdit ağacı, belirli bir saldırıyı bağlamak için gerekli adımları ve adımlar arasındaki ilişkileri gösterir. Ana hat, tehdit ağacına alternatiftir.

Ana hat, belirli bir tehdide saldırma adımlarını hiyerarşik sırada listeler. Örneğin:

1.0 Cihazın yanıt vermeyi durdurmasına neden olun.

1.1 Hata sekansında IOCTLS çıkar.

1.1.1 Cihazın başarısız olmasına neden olan sırayı belirleyin.

1.1.2 İç IOCTL'ler vermek için yükseltilmiş ayrıcalık alın.

Her iki teknik de hangi tehditlerin en tehlikeli olduğunu ve tasarımınızdaki hangi güvenlik açıklarının en kritik olduğunu anlamanıza yardımcı olabilir.

Hızlı yol tehdit modellemesi

Kaynaklar sınırlıysa, tam bir tehdit modeli diyagramı oluşturmak yerine, sürücüye yönelik güvenlik risklerini değerlendirmeye yardımcı olacak bir özet ana hattı oluşturulabilir. Örneğin, aşağıdaki metinde, önceki örnekte açıklanan örnek sürücüde diyagrama alınan bazı yüzey alanları açıklanmaktadır.

Sürücü, çeşitli istek türlerinde işletim sisteminden veri alır:

• DriverEntry, DriverUnload ve AddDevice yordamlarına yapılan çağrılar aracılığıyla sürücü ve cihazı için yönetim görevlerini gerçekleştirme istekleri
• Tak Çalıştır istekleri (IRP_MJ_PNP)
• Güç yönetimi istekleri (IRP_MJ_POWER)
• İç cihaz G/Ç denetim istekleri (IRP_MJ_INTERNAL_DEVICE_CONTROL)

Bu isteklere yanıt olarak, veri sürücüden işletim sistemine durum bilgisi olarak geri akar. Sürücü, aşağıdaki istek türlerinde bir kullanıcı işleminden veri alır:

• İstek oluşturma, okuma ve yazma (IRP_MJ_CREATE, IRP_MJ_READ veya IRP_MJ_WRITE)
• Genel cihaz G/Ç denetim istekleri (IRP_MJ_DEVICE_ CONTROL)

Bu isteklere yanıt olarak çıkış verileri ve durum bilgileri sürücüden kullanıcı işlemine geri döner.

Sürücünüze veri akışıyla ilgili bu temel anlayışı kullanarak olası tehditler için her giriş ve çıkış alanını inceleyebilirsiniz.

Tehdit değerlendirmesi için DREAD yaklaşımı

Bir sürücünün nasıl ve nerede saldırıya uğrayabileceğini belirlemek yeterli değildir. Daha sonra bu olası tehditleri değerlendirmeli, göreli önceliklerini belirlemeli ve bir azaltma stratejisi oluşturmalısınız.

DREAD, yazılıma yönelik tehditleri değerlendirmek için beş ölçüt açıklayan bir kısaltmadır. DREAD' nin kısaltması:

• Damage
• Reniden üretilebilirlik
• Eistismar edilebilirlik
• Etkilenen kullanıcılar
• Keşfedilebilirlik

Sürücünüze yönelik tehditlere öncelik vermek için, her tehdidi 1 ile 10 arasında derecelendirin ve ardından puanları 5'e (ölçüt sayısı) bölün. Sonuç, her tehdit için 1 ile 10 arasında bir sayısal puandır. Yüksek puanlar ciddi tehditlere işaret eder.

• Hasar. Bir güvenlik saldırısından kaynaklanan hasarı değerlendirmek, tehdit modellemesinin kritik bir parçasıdır. Hasar, veri kaybı, donanım veya medya hatası, standart dışı performans veya cihazınız ve işletim ortamı için geçerli olan benzer ölçüleri içerebilir.

• Yeniden üretilebilirlik , belirtilen saldırı türünün ne sıklıkta başarılı olacağını gösteren bir ölçüdür. Kolayca yeniden üretilebilen bir tehdit, nadiren veya öngörülemeyen bir güvenlik açığından yararlanma olasılığından daha yüksektir. Örneğin, varsayılan olarak yüklenen veya her olası kod yolunda kullanılan özelliklere yönelik tehditler yüksek oranda yeniden üretilebilir.

• Özelleştirilebilirlik, bir saldırıyı gerçekleştirmek için gereken çabayı ve uzmanlığı değerlendirir. Nispeten deneyimsiz bir üniversite öğrencisi tarafından saldırıya uğrayabilecek bir tehdit yüksek oranda sömürülebilir. Yüksek vasıflı personel gerektiren ve yapılması pahalı olan bir saldırı daha az sömürülebilir.

  Sömürüyü değerlendirirken olası saldırgan sayısını da göz önünde bulundurun. Uzak, anonim herhangi bir kullanıcı tarafından istismar edilebilen bir tehdit, fiziksel olarak, yüksek yetkilendirilmiş bir kullanıcı gerektiren bir tehditten daha istismar edilebilir.

• Etkilenen Kullanıcılar. Bir saldırıdan etkilenebilen kullanıcı sayısı, bir tehdidi değerlendirmede önemli bir faktördür. En fazla bir veya iki kullanıcıyı etkileyebilecek bir saldırı, bu ölçüde görece daha düşük bir değere sahip olacaktır. Buna karşılık, bir ağ sunucusunu kilitleyen bir hizmet reddi saldırısı binlerce kullanıcıyı etkileyebilir ve bu nedenle çok daha yüksek oranda hızlanır.

• Bulunabilirlik , bir tehdidin kötüye kullanılmasının olasılığıdır. Bulunabilirliği doğru tahmin etmek zordur. En güvenli yaklaşım, herhangi bir güvenlik açığının nihai olarak avantajından yararlanılacağını ve sonuç olarak tehdidin göreli derecelendirmesini oluşturmak için diğer önlemlere güveneceğini varsaymaktır.

Örnek: DREAD kullanarak tehditleri değerlendirme

Yukarıda açıklanan örnekten devam edersek, aşağıdaki tabloda tasarımcının varsayımsal hizmet reddi saldırısını nasıl değerlendirebileceği gösterilmektedir:

DREAD Ölçütü	Puan	Yorumlar
Hasar	8	Geçici olarak çalışmayı kesintiye uğratır, ancak kalıcı bir hasara veya veri kaybına neden olmaz.
Yeniden üretilebilirlik	10	Cihazın her seferinde başarısız olmasına neden olur.
İstismar Edilebilirlik	7	Komut dizisini belirlemek için odaklanmış bir çaba gerektirir.
Etkilenen kullanıcılar	10	Bu cihazın piyasadaki tüm modellerini etkiler.
Bulunabilirlik	10	Her olası tehdidin bulunacağını varsayar.
Toplam:	9.0	Bu sorunu azaltmak yüksek önceliklidir.

Tehditleri Azaltma

Sürücü tasarımınız, modelinizin kullanıma açtığı tüm tehditlere karşı önlem almalıdır. Ancak bazı durumlarda azaltma pratik olmayabilir. Örneğin, çok az kullanıcıyı etkileyebilecek ve veri kaybına veya sistem kullanılabilirliğine neden olma olasılığı düşük bir saldırı düşünün. Böyle bir tehdidin azaltılması birkaç ay ek çaba gerektiriyorsa, bunun yerine sürücüyü test etmek için ek zaman harcamayı tercih edebilirsiniz. Bununla birlikte, kötü amaçlı bir kullanıcının güvenlik açığını bulup bir saldırıyı bağlama olasılığının yüksek olduğunu ve ardından sürücünün sorun için bir düzeltme eki gerektireceğini unutmayın.

Daha geniş bir Güvenlik Geliştirme Yaşam Döngüsü sürecine tehdit modelleme dahil

Tehdit modelleme işlemini daha geniş bir Güvenli Geliştirme Yaşam Döngüsü - SDL'ye dahil etmeyi göz önünde bulundurun.

Microsoft SDL işlemi, tek bir geliştirici de dahil olmak üzere herhangi bir kuruluş boyutuna uyacak şekilde değiştirilebilen bir dizi önerilen yazılım geliştirme işlemi sağlar. Yazılım geliştirme sürecinize SDL önerilerinin bileşenlerini eklemeyi göz önünde bulundurun.

Daha fazla bilgi için bkz. Microsoft Güvenlik Geliştirme Yaşam Döngüsü (SDL) – İşlem Kılavuzu.

Eğitim ve kuruluş özellikleri - Yazılım güvenlik açıklarını tanıma ve düzeltme yeteneğinizi genişletmek için yazılım geliştirme güvenlik eğitimini takip edin.

Microsoft, dört temel SDL Eğitim sınıfını indirilebilir hale getirir. Microsoft Güvenlik Geliştirme Yaşam Döngüsü Temel Eğitim sınıfları

SDL eğitimi hakkında daha ayrıntılı bilgi için bu teknik incelemeye bakın. Microsoft SDL için Temel Yazılım Güvenliği Eğitimi

Gereksinimler ve tasarım - Geliştirme ekipleri önemli nesneleri tanımlayıp güvenlik ve gizliliği tümleştirebildiğinden, güvenilir yazılım oluşturmak için en iyi fırsat yeni bir sürümün veya yeni sürümün ilk planlama aşamalarındadır. Bu da plan ve zamanlamalarda kesintiyi en aza indirir.

Bu aşamada önemli bir çıkış, belirli güvenlik hedefleri belirlemektir. Örneğin, tüm kodunuzun sıfır uyarı içeren "Tüm Kurallar" Visual Studio kod analizini geçirmesi gerektiğine karar vermek.

Uygulama - Tüm geliştirme ekipleri, derleyici/bağlayıcı seçenekleri ve uyarıları gibi onaylı araçların ve ilişkili güvenlik denetimlerinin listesini tanımlamalı ve yayımlamalıdır.

Bir sürücü geliştirici için yararlı işlerin çoğu bu aşamada yapılır. Kod yazıldığında olası zayıflık açısından gözden geçirilir. Kod analizi ve sürücü doğrulayıcı gibi araçlar, kodda sağlamlaştırılabilir alanları aramak için kullanılır.

Doğrulama - Doğrulama, yazılımın işlevsel olarak tamamlandığı ve gereksinimlerde ve tasarım aşamasında özetlenen güvenlik hedeflerine karşı test edilen noktadır.

Güvenlik tasarımı hedeflerinin karşılandığını ve kodun göndermeye hazır olduğunu doğrulamak için binscope ve fuzz tester gibi ek araçlar kullanılabilir

Sürüm ve yanıt - Bir ürünü kullanıma sunma hazırlığında, yeni tehditlere yanıt vermek için ne yapacağınızı ve sevk edildikten sonra sürücüye nasıl hizmet verileceğini açıklayan bir olay yanıt planı oluşturmak tercih edilir. Bu işi önceden yapmak, gönderilen kodda güvenlik sorunları tespit edilirse daha hızlı yanıt verebilmeniz anlamına gelir.

SDL işlemi hakkında daha fazla bilgi için şu ek kaynaklara bakın:

• Bu birincil Microsoft SDL sitesidir ve SDL'ye genel bir bakış sağlar. https://www.microsoft.com/sdl

• Bu blogda, Michael Howard ve Steve Lipner tarafından oluşturulan The Security Development Lifecycle: SDL'nin ücretsiz bir kopyasının nasıl indirildiği açıklanır. https://blogs.msdn.microsoft.com/microsoft_press/2016/04/19/free-ebook-the-security-development-lifecycle/

• Bu sayfa ek SDL yayınlarına bağlantılar sağlar. https://www.microsoft.com/SDL/Resources/publications.aspx

Eylem çağrısı

Sürücü geliştiricileri için:

• Tehdit modellemesini sürücü tasarımının bir parçası yapın.
• Sürücü kodunuzdaki tehditleri verimli bir şekilde azaltmak için adımlar atın.
• Sürücünüz ve cihaz türünüz için geçerli olan güvenlik ve güvenilirlik sorunları hakkında bilgi sahibi olun. Daha fazla bilgi için Windows Cihaz Sürücü Seti'nin (WDK) cihaza özgü bölümlerine bakın.
• Kullanıcı istekleri sürücünüze ulaşmadan önce işletim sistemi, G/Ç yöneticisi ve üst düzey sürücülerin hangi denetimleri gerçekleştirdiğini ve hangi denetimlerin gerçekleştirmediğini anlayın.
• Sürücünüzü test etmek ve doğrulamak için WDK'den sürücü doğrulayıcı gibi araçları kullanın.
• Bilinen tehditlerin ve yazılım güvenlik açıklarının genel veritabanlarını gözden geçirin.

Ek sürücü güvenlik kaynakları için bkz . Sürücü Güvenliği Denetim Listesi.

Yazılım Güvenliği Kaynakları

Kitaplar

Writing Secure Code, Second Edition by Michael Howard and David LeBlanc

Yazılım Güvenliğinin 24 Ölümcül Günahı: Programlama Hataları ve Bunları Düzeltme Yolları, Michael Howard, David LeBlanc ve John Viega tarafından yazılan Birinci Baskı

Yazılım güvenliği değerlendirmesi sanatı: Mark Dowd, John McDonald ve Justin Schuh tarafından yazılım güvenlik açıklarını tanımlama ve önleme

Microsoft Donanım ve Sürücü Geliştirici Bilgileri

Windows Sürücüleri'nde Mantığı İptal Etme teknik incelemesi

Windows güvenlik modeli: Her sürücü yazıcının bilmesi gerekenler

Microsoft Windows Sürücü Geliştirme Seti (DDK)

Bkz. Sürücü Programlama TeknikleriKernel-Mode Sürücü Mimarisi'nde

Test Araçları

Windows Donanım Laboratuvar Seti için Performans ve uyumluluğu test edin bölümüne bakın.

Bilinen tehditlerin ve yazılım güvenlik açıklarının genel veritabanları

Yazılım tehditleri bilginizi genişletmek için, bilinen tehditlerin ve yazılım güvenlik açıklarının genel veritabanlarını gözden geçirin.

• Yaygın Güvenlik Açıkları ve Etkilenmeler (CVE): https://cve.mitre.org/
• Ortak Zayıflık Envanteri: https://cwe.mitre.org/
• Yaygın Saldırı Düzeni Numaralandırması ve Sınıflandırması: https://capec.mitre.org/index.html
• NIST, güvenlik açıklarının nasıl kataloglandığını açıklayan bir site tutar: https://samate.nist.gov/BF/

Ayrıca Bkz.

sürücü güvenlik denetim listesi