ドライバーの脅威モデリング

ドライバーの作成者とアーキテクトは、脅威モデリングを任意のドライバーの設計プロセスの不可欠な部分にする必要があります。 このトピックでは、Windows ドライバーの脅威モデルを作成するためのガイドラインを示します。

セキュリティは、すべてのドライバーの基本的な設計ポイントである必要があります。 成功した製品はターゲットです。 Windows 用のドライバーを作成している場合は、どこかで、誰かがドライバーを使用してシステムのセキュリティを侵害しようとする可能性があると想定する必要があります。

セキュリティで保護されたドライバーの設計には、次の作業が含まれます。

• ドライバーが攻撃に対して脆弱になる可能性があるポイントを特定します。
• このような各時点でマウントできる攻撃の種類を分析する。
• ドライバーがこのような攻撃を阻止するように設計されていることを確認します。

脅威モデリングは、これらの重要な設計タスクに対する構造化されたアプローチです。 脅威モデルは、資産に対する脅威を分類して分析する方法です。 ドライバー ライターの観点からは、資産は、コンピューターまたはネットワーク上のハードウェア、ソフトウェア、およびデータです。

脅威モデルは、次の質問に回答します。

• 保護が必要な資産はどれですか?
• 資産はどのような脅威に対して脆弱ですか?
• 各脅威の重要度または可能性はどのくらいですか?
• 脅威を軽減する方法

脅威モデリングは、後から取り組むのではなく、セキュリティが製品に組み込まれるようにするため、ソフトウェア設計の重要な部分です。 優れた脅威モデルは、設計プロセス中にバグを見つけて防ぐのに役立ちます。そのため、後でコストがかかる可能性のあるパッチや、組織に対する評判の低下の可能性を排除できます。

このセクションでは、ドライバーの設計に脅威モデリングの原則を適用し、ドライバーが影響を受けやすい脅威の例を示します。 ソフトウェア設計の脅威モデリングの詳細については、これらのリソースを参照してください。

• Microsoft SDL Web サイト:

  https://www.microsoft.com/sdl

• Microsoft SDL の簡略化された実装:

  ホワイト ペーパーをダウンロードする

• このブログ エントリでは、Michael Howard と Steve Lipner による、 セキュリティ開発ライフサイクル :SDL の無料コピーをダウンロードする方法について説明します。

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

ドライバーの脅威モデルを作成する

脅威モデルを作成するには、ドライバーの設計、ドライバーが公開される可能性がある脅威の種類、および特定の脅威を悪用するセキュリティ攻撃の結果を十分に理解する必要があります。 ドライバーの脅威モデルを作成したら、潜在的な脅威を軽減する方法を決定できます。

脅威モデリングは、コーディング中に無計画ではなく、ドライバーの設計時に整理された構造化された方法で実行される場合に最も効果的です。 構造化されたアプローチを使用すると、設計の脆弱性を発見する可能性が高くなり、モデルが包括的であることを確認するのに役立ちます。

脅威モデリング作業を整理する方法の 1 つは、次の手順に従う方法です。

1. ドライバーを介したデータ フローを示す構造化図を作成します。 ドライバーが実行できるすべてのタスクと、ドライバーからのすべての入力と出力のソースと宛先を含めます。 正式なデータ フロー図または同様の構造化図は、ドライバーを介してデータのパスを分析し、ドライバーの外部インターフェイス、境界、および相互作用を識別するのに役立ちます。
2. データ フロー図に基づいて、潜在的なセキュリティ上の脅威を分析します。
3. 前の手順で特定した脅威を評価し、それらを軽減する方法を決定します。

データ フローダイアグラムを作成する

データ フロー図は、ドライバーとそれが対話する外部エンティティ (通常はオペレーティング システム、ユーザー プロセス、デバイス) の間のデータ フローを概念的に示しています。 正式なデータ フロー図では、次の記号を使用します。

次の図は、仮想カーネル モード Windows ドライバー モデル (WDM) ドライバーのサンプル データ フロー図を示しています。 特定の種類のドライバーのアーキテクチャに関係なく、概念モデルは同じです。すべてのデータ パスを表示し、ドライバーを出入りするデータの各ソースを識別します。

手記 前の図は、ユーザー プロセスとドライバーの間で直接流れるデータを示しており、中間ドライバーは省略しています。 ただし、実際には、すべての要求は I/O マネージャーを通過し、特定のドライバーに到達する前に 1 つ以上の上位レベルのドライバーを走査する可能性があります。 この図では、データの元のソースの重要性と、データを提供したスレッドのコンテキストを強調するために、これらの中間手順を省略しています。 カーネル モード ドライバーは、ユーザー モードで生成されたデータを検証する必要があります。

オペレーティング システムからの要求、ユーザー プロセスからの要求、またはデバイスからの要求 (通常は割り込み) により、ドライバーに情報が入力されます。

前の図のドライバーは、いくつかの種類の要求でオペレーティング システムからデータを受信します。

• DriverEntry、DriverUnload、および AddDevice ルーチンの呼び出しを通じて、ドライバーとそのデバイスの管理タスクを実行する要求
• プラグ アンド プレイ要求 (IRP_MJ_PNP)
• 電源管理要求 (IRP_MJ_POWER)
• 内部デバイス I/O 制御要求 (IRP_MJ_INTERNAL_DEVICE_CONTROL)

これらの要求に応じて、ドライバーからオペレーティング システムに状態情報としてデータが戻ります。 図のドライバーは、次の種類の要求のユーザー プロセスからデータを受け取ります。

• 要求の作成、読み取り、書き込み (IRP_MJ_CREATE、IRP_MJ_READ、またはIRP_MJ_WRITE)
• パブリック デバイス I/O 制御要求 (IRP_MJ_DEVICE_ CONTROL)

これらの要求に応じて、ドライバーからユーザー プロセスに戻ってデータと状態情報を出力します。

最後に、デバイスの状態を変更するデバイス I/O 操作またはユーザー 操作 (CD ドライブでトレイを開くなど) のため、ドライバーはデバイスからデータを受信します。 同様に、ドライバーからのデータは、I/O 操作中にデバイスに送信され、デバイスの状態が変化します。

前の図は、広範な概念レベルでのドライバー データ フローを示しています。 各円は比較的大きなタスクを表し、詳細が不足しています。 場合によっては、サンプルなどの 1 レベルの図がデータ ソースとパスを理解するのに十分です。 ドライバーがさまざまなソースからさまざまな種類の I/O 要求を処理する場合は、詳細を表示する 1 つ以上の追加の図を作成する必要があります。 たとえば、次の図のように、"I/O 要求の処理" というラベルの付いた円が別の図に展開される場合があります。

2 番目の図は、最初の図の I/O 要求の種類ごとに個別のタスクを示しています。 (わかりやすくするために、デバイスへのデータ パスは省略されています)。

図に示す外部エンティティと入力と出力の種類は、デバイスの種類によって異なる場合があります。 たとえば、Windows には、多くの一般的なデバイスの種類のクラス ドライバーが用意されています。 システム提供のクラス ドライバーは、ベンダーが提供するミニドライバーで動作します。通常は、コールバック ルーチンのセットを含むダイナミック リンク ライブラリ (DLL) です。 ユーザー I/O 要求はクラス ドライバーに送信され、ミニドライバーのルーチンを呼び出して特定のタスクを実行します。 ミニドライバーは通常、入力として I/O 要求パケット全体を受信しません。代わりに、各コールバック ルーチンは、その特定のタスクに必要なデータのみを受け取ります。

データ フロー 図を作成するときは、ドライバー要求のさまざまなソースを覚えておいてください。 ユーザーのコンピューターで実行されるコードは、Microsoft Office などの既知のアプリケーションから、疑わしい可能性のある配信元のフリーウェア、共有ウェア、Web ダウンロードまで、ドライバーへの I/O 要求を生成する可能性があります。 特定のデバイスによっては、会社がデバイスをサポートするために出荷するメディア コーデックまたはサード パーティ製のフィルターも考慮する必要があります。 使用できるデータ ソースは、次のとおりです。

• IRP_MJ_XXX要求をドライバーが処理する
• ドライバーが定義または処理する IOCTL
• ドライバーが呼び出す API
• コールバック ルーチン
• ドライバーが公開するその他のインターフェイス
• ドライバーが読み取りまたは書き込むファイル (インストール時に使用されるものも含む)
• ドライバーが読み取りまたは書き込みを行うレジストリ キー
• ドライバーが使用する構成プロパティページや、ユーザーが提供するその他の情報

モデルでは、ドライバーのインストールと更新の手順についても説明する必要があります。 ドライバーのインストール中に読み取りまたは書き込まれるすべてのファイル、ディレクトリ、およびレジストリ エントリを含めます。 また、デバイス インストーラー、共同インストーラー、およびプロパティ ページで公開されるインターフェイスについても検討してください。

ドライバーが外部エンティティとデータを交換する時点は、攻撃に対して脆弱になる可能性があります。

潜在的な脅威を分析する

ドライバーが脆弱になる可能性があるポイントを特定したら、各ポイントで発生する可能性のある脅威の種類を特定できます。 次の種類の質問について考えてみましょう。

• 各リソースを保護するためのセキュリティ メカニズムは何ですか?
• すべての遷移とインターフェイスが適切にセキュリティで保護されていますか?
• 機能を不適切に使用すると、意図せずにセキュリティが侵害される可能性がありますか?
• 機能の悪意のある使用によってセキュリティが侵害される可能性がありますか?
• 既定の設定では適切なセキュリティが提供されますか?

脅威の分類に対する STRIDE アプローチ

頭字語 STRIDE には、ソフトウェアに対する脅威の 6 つのカテゴリが記述されています。 この頭字語の由来は次のとおりです。

• なりすまし
• Tアンペア
• R拒絶
• 情報の開示
• サービス拒否
• 特権の昇格

STRIDE をガイドとして使用すると、ドライバーを対象とする攻撃の種類に関する詳細な質問を行うことができます。 目標は、ドライバーの各脆弱なポイントで発生する可能性がある攻撃の種類を特定し、考えられる攻撃ごとにシナリオを作成することです。

• スプーフィング は、他のユーザーの資格情報を使用して、アクセスできない資産にアクセスします。 プロセスは、偽造された資格情報または盗まれた資格情報を渡すことによって、スプーフィング攻撃をマウントします。

• 改ざん は、攻撃をマウントするためにデータを変更しています。 たとえば、ドライバーの署名とアクセス制御リスト (ACL) によって必要なドライバー ファイルが適切に保護されていない場合、ドライバーは改ざんの影響を受ける可能性があります。 このような状況では、悪意のあるユーザーがファイルを変更し、システムのセキュリティを侵害する可能性があります。

• 否認は 、ユーザーがアクションの実行を拒否したが、アクションのターゲットに他の方法で証明する方法がない場合に発生します。 ドライバーは、セキュリティを侵害する可能性のあるアクションをログに記録しない場合、否認の脅威の影響を受ける可能性があります。 たとえば、ビデオ デバイスのドライバーは、フォーカス、スキャン領域、画像キャプチャの頻度、キャプチャされた画像のターゲットの場所など、デバイスの特性を変更する要求をログに記録しない場合、否認の影響を受ける可能性があります。 結果のイメージは破損している可能性がありますが、システム管理者は、問題の原因となったユーザーを特定する方法がありません。

• 情報漏えい の脅威は、名前が示すとおりです。情報を表示するアクセス許可を持たないユーザーに対する情報の開示です。 ユーザー バッファーとの間で情報を渡すドライバーは、情報漏えいの脅威の影響を受けやすくなります。 情報漏えいの脅威を回避するには、ドライバーは各ユーザー バッファーの長さを検証し、データを書き込む前にバッファーをゼロ初期化する必要があります。

• サービス拒否 攻撃は、有効なユーザーがリソースにアクセスする能力を脅かします。 リソースには、ディスク領域、ネットワーク接続、または物理デバイスがあります。 許容できないレベルまでパフォーマンスが低下する攻撃も、サービス拒否攻撃と見なされます。 ユーザー プロセスがシステム リソースを不必要に独占できるようにするドライバーは、リソース消費によって他の有効なユーザーがタスクを実行できない場合、サービス拒否攻撃の影響を受ける可能性があります。

  たとえば、ドライバーは、IRQL = PASSIVE_LEVEL で実行中に、セマフォを使用してデータ構造を保護できます。 ただし、ドライバーは、非同期プロシージャ 呼び出し (APC) の配信を無効にして再度有効にする KeEnterCriticalRegion/KeLeaveCriticalRegion ペア内のセマフォを取得して解放する必要があります。 ドライバーがこれらのルーチンを使用できない場合、APC は、オペレーティング システムがセマフォを保持しているスレッドを中断する可能性があります。 その結果、他のプロセス (管理者によって作成されたものを含む) が構造にアクセスできなくなります。

• 特権の昇格攻撃は、特権のないユーザーが特権状態を取得した場合に発生する可能性があります。 ユーザー モード ハンドルを ZwXxx ルーチンに渡すカーネル モード ドライバーは、 ZwXxx ルーチンがセキュリティ チェックをバイパスするため、特権昇格攻撃に対して脆弱です。 カーネル モード ドライバーは、ユーザー モードの呼び出し元から受け取るすべてのハンドルを検証する必要があります。

  特権の昇格攻撃は、カーネル モード ドライバーが IRP ヘッダーの RequestorMode 値に依存して、I/O 要求がカーネル モードまたはユーザー モードの呼び出し元から送信されたかどうかを判断する場合にも発生する可能性があります。 ネットワークまたはサーバー サービス (SRVSVC) から到着する IRP では、要求の配信元に関係なく、 RequestorMode の値は KernelMode です。 このような攻撃を回避するには、ドライバーは、単に RequestorMode の値を使用するのではなく、このような要求に対してアクセス制御チェックを実行する必要があります。

ドライバー分析手法

分析を整理する簡単な方法は、潜在的な脅威と共に脆弱な領域と、脅威の種類ごとに 1 つ以上のシナリオを一覧表示することです。

徹底的な分析を実行するには、ドライバー内の潜在的に脆弱なポイントごとに脅威の可能性を調べる必要があります。 脆弱な各ポイントで、可能な脅威 (スプーフィング、改ざん、否認、情報漏えい、サービス拒否、特権の昇格) の各カテゴリを決定します。 次に、妥当な脅威ごとに 1 つ以上の攻撃シナリオを作成します。

たとえば、前の図に示すように、IRP_MJ_DEVICE_CONTROL要求のデータ フローについて考えてみましょう。 次の表は、このような要求を処理するときにドライバーが発生する可能性がある 2 種類の脅威を示しています。

脅威ツリーとアウトラインは、このような複雑なシナリオをモデル化する場合に役立ちます。

脅威ツリーは、脅威または脆弱性の階層を示す図です。基本的に、脅威ツリーは、攻撃をマウントする際の悪意のあるユーザーの手順を模倣します。 攻撃の最終的な目標は、ツリーの上部にあります。 各下位レベルには、攻撃を実行するために必要な手順が表示されます。 次の図は、前の例のサービス拒否シナリオの単純な脅威ツリーです。

脅威ツリーには、特定の攻撃をマウントするために必要な手順と、手順間の関係が表示されます。 アウトラインは、脅威ツリーの代替手段です。

アウトラインは、特定の脅威を攻撃する手順を階層順に一覧表示するだけです。 例えば次が挙げられます。

1.0 デバイスの応答を停止させる。

1.1 障害シーケンスで IOCTLS を実行します。

1.1.1 デバイスが失敗する原因となるシーケンスを特定します。

1.1.2 内部 IOCTL を発行するための昇格された特権を取得します。

どちらの手法でも、最も危険な脅威と、設計のどの脆弱性が最も重要であるかを理解するのに役立ちます。

高速パスの脅威モデリング

リソースが制限されている場合は、完全な脅威モデル図を作成する代わりに、概要アウトラインを作成して、ドライバーに対するセキュリティ リスクを評価できます。 たとえば、次のテキストでは、前の例で説明したドライバーの例で図に示したサーフェス領域の一部について説明します。

ドライバーは、いくつかの種類の要求でオペレーティング システムからデータを受信します。

• DriverEntry、DriverUnload、および AddDevice ルーチンの呼び出しを通じて、ドライバーとそのデバイスの管理タスクを実行する要求
• プラグ アンド プレイ要求 (IRP_MJ_PNP)
• 電源管理要求 (IRP_MJ_POWER)
• 内部デバイス I/O 制御要求 (IRP_MJ_INTERNAL_DEVICE_CONTROL)

これらの要求に応じて、ドライバーからオペレーティング システムに状態情報としてデータが戻ります。 ドライバーは、次の種類の要求でユーザー プロセスからデータを受信します。

• 要求の作成、読み取り、書き込み (IRP_MJ_CREATE、IRP_MJ_READ、またはIRP_MJ_WRITE)
• パブリック デバイス I/O 制御要求 (IRP_MJ_DEVICE_ CONTROL)

これらの要求に応じて、ドライバーからユーザー プロセスに戻ってデータと状態情報を出力します。

ドライバーへのデータ フローに関するこの基本的な理解を使用して、各入力領域と出力領域で考えられる脅威を調べることができます。

脅威評価に対する DREAD アプローチ

ドライバーが攻撃される可能性がある方法と場所を決定するだけでは不十分です。 その後、これらの潜在的な脅威を評価し、それらの相対的な優先順位を決定し、軽減戦略を策定する必要があります。

DREAD は、ソフトウェアに対する脅威を評価するための 5 つの基準を記述する頭字語です。 DREAD が意味するものは:

• ダメージ
• R再現性
• Exploitability
• 影響を受けたユーザー
• D発見しやすさ

ドライバーに対する脅威に優先順位を付けるために、DREAD 評価基準の 5 つすべてに対して 1 ~ 10 の各脅威をランク付けし、スコアを追加して 5 (条件の数) で除算します。 結果は、脅威ごとに 1 から 10 までの数値スコアになります。 ハイ スコアは重大な脅威を示します。

• ダメージ。 セキュリティ攻撃の結果として生じる可能性のある損害の評価は、明らかに脅威モデリングの重要な部分です。 破損には、データの損失、ハードウェアまたはメディアの障害、標準以下のパフォーマンス、またはデバイスとその動作環境に適用される同様の対策が含まれます。

• 再現性 は、指定された種類の攻撃が成功する頻度の尺度です。 再現しやすい脅威は、まれに発生する脆弱性や予測不可能な脆弱性よりも悪用される可能性が高くなります。 たとえば、既定でインストールされている機能や、潜在的なすべてのコード パスで使用される機能に対する脅威は、高い再現性を備えています。

• 悪用可能性 は、攻撃をマウントするために必要な労力と専門知識を評価します。 比較的経験の浅い大学生によって攻撃される可能性のある脅威は、非常に悪用可能です。 高度なスキルを持つ担当者を必要とし、実行にコストがかかる攻撃は悪用不可能です。

  悪用可能性を評価する場合は、潜在的な攻撃者の数も考慮してください。 リモートの匿名ユーザーによって悪用される可能性がある脅威は、オンサイトの高い権限を持つユーザーを必要とする脅威よりも悪用可能です。

• 影響を受けるユーザー。 攻撃の影響を受ける可能性のあるユーザーの数は、脅威を評価する際のもう 1 つの重要な要因です。 最大で 1 人または 2 人のユーザーに影響を与える可能性がある攻撃は、この対策の評価が比較的低くなります。 逆に、ネットワーク サーバーをクラッシュするサービス拒否攻撃は、何千人ものユーザーに影響を与える可能性があるため、はるかに高いレートになります。

• 検出可能性 は、脅威が悪用される可能性です。 検出可能性を正確に見積もるのは困難です。 最も安全なアプローチは、すべての脆弱性が最終的に利用され、その結果、脅威の相対的なランク付けを確立するために他の手段に依存することを想定することです。

サンプル: DREAD を使用した脅威の評価

上で説明した例を続けて、次の表は、デザイナーが架空のサービス拒否攻撃を評価する方法を示しています。

脅威の軽減

ドライバーの設計は、モデルがさらすすべての脅威を軽減する必要があります。 ただし、場合によっては、軽減策が実用的でない場合があります。 たとえば、ごく少数のユーザーに影響を与える可能性があり、データやシステムの使いやすさが失われる可能性が低い攻撃を考えてみましょう。 このような脅威を軽減するために数か月の追加作業が必要な場合は、代わりにドライバーのテストに追加の時間を費やすことを合理的に選択できます。 それでも、最終的には悪意のあるユーザーが脆弱性を見つけて攻撃をマウントする可能性があり、ドライバーには問題の修正プログラムが必要になる可能性があることを覚えておいてください。

より広範なセキュリティ開発ライフサイクル プロセスに脅威モデリングを含める

セキュリティで保護された開発ライフサイクル (SDL) に脅威モデリング プロセスを含める方法を検討します。

Microsoft SDL プロセスには、1 人の開発者を含め、あらゆる規模の組織に合わせて変更できる、推奨されるソフトウェア開発プロセスが多数用意されています。 ソフトウェア開発プロセスに SDL レコメンデーションのコンポーネントを追加することを検討してください。

詳細については、「 Microsoft セキュリティ開発ライフサイクル (SDL) – プロセス ガイダンス」を参照してください。

トレーニングと組織の機能 - ソフトウェアの脆弱性を認識して修復する能力を拡張するために、ソフトウェア開発のセキュリティ トレーニングを追求します。

Microsoft は、4 つのコア SDL トレーニング クラスをダウンロードできるようにします。 Microsoft セキュリティ開発ライフサイクル コア トレーニング クラス

SDL トレーニングの詳細については、このホワイト ペーパーを参照してください。 Microsoft SDL の基本的なソフトウェア セキュリティ トレーニング

要件と設計 - 信頼できるソフトウェアを構築する最適な機会は、新しいリリースまたは新しいバージョンの初期計画段階です。開発チームは主要なオブジェクトを特定し、セキュリティとプライバシーを統合できるため、計画とスケジュールの中断を最小限に抑えることができます。

このフェーズの主な出力は、特定のセキュリティ目標を設定することです。 たとえば、すべてのコードが、警告がゼロの Visual Studio コード分析 "すべてのルール" に合格する必要があることを決定します。

実装 - すべての開発チームは、承認されたツールとそれに関連するセキュリティ チェック (コンパイラ/リンカー オプション、警告など) の一覧を定義して公開する必要があります。

ドライバー開発者にとって、ほとんどの便利な作業はこのフェーズで行われます。 コードが記述されると、考えられる弱点が確認されます。 コード分析やドライバー検証ツールなどのツールは、強化できるコード内の領域を検索するために使用されます。

検証 - 検証は、ソフトウェアが機能的に完了し、要件と設計フェーズで概説されているセキュリティ目標に照らしてテストされるポイントです。

binscope やファジー テスターなどの追加ツールを使用して、セキュリティ設計の目標が満たされ、コードを発送する準備ができていることを検証できます

リリースと対応 - 製品をリリースする準備として、新しい脅威に対応するために何を行うか、および出荷後にドライバーにサービスを提供する方法を説明するインシデント対応計画を作成することをお勧めします。 この作業を事前に行うと、出荷されたコードでセキュリティの問題が特定された場合に、より迅速に対応できるようになります。

SDL プロセスの詳細については、次の追加リソースを参照してください。

• これは Microsoft SDL のプライマリ サイトであり、SDL の概要を示します。 https://www.microsoft.com/sdl

• このブログでは、Michael Howard と Steve Lipner による 、セキュリティ開発ライフサイクル (SDL) の無料コピーをダウンロードする方法について説明します。 https://blogs.msdn.microsoft.com/microsoft_press/2016/04/19/free-ebook-the-security-development-lifecycle/

• このページでは、追加の SDL パブリケーションへのリンクを提供します。 https://www.microsoft.com/SDL/Resources/publications.aspx

アクションへの誘い

ドライバー開発者向け:

• 脅威モデリングをドライバー設計の一部にします。
• ドライバー コードの脅威を効率的に軽減するための手順を実行します。
• ドライバーとデバイスの種類に適用されるセキュリティと信頼性の問題について理解します。 詳細については、Windows デバイス ドライバー キット (WDK) のデバイス固有のセクションを参照してください。
• ユーザー要求がドライバーに到達する前に、オペレーティングシステム、I/Oマネージャー、および上位レベルのドライバーが行うチェックと行わないチェックを理解します。
• ドライバー検証ツールなどの WDK のツールを使用して、ドライバーをテストおよび検証します。
• 既知の脅威とソフトウェアの脆弱性のパブリック データベースを確認します。

その他のドライバー セキュリティ リソースについては、「 ドライバーセキュリティチェックリスト」を参照してください。

ソフトウェア セキュリティ リソース

書物

Michael Howard と David LeBlanc によるセキュア コードの記述(第 2 版)

24 ソフトウェアセキュリティの致命的な罪:プログラミングの欠陥とその修正方法、Michael Howard、David LeBlanc、John Viega による初回版

ソフトウェア セキュリティ評価の技術: Mark Dowd、John McDonald、Justin Schuh によるソフトウェアの脆弱性の特定と防止

Microsoft ハードウェアとドライバーの開発者情報

Windows ドライバーのロジックのキャンセル に関するホワイト ペーパー

Windows セキュリティ モデル: すべてのドライバー ライターが知る必要がある内容

Microsoft Windows ドライバー開発キット (DDK)

ドライバー プログラミング手法はKernel-Mode ドライバー アーキテクチャを参照してください。

テスト ツール

パフォーマンスと互換性については、テストの Windows ハードウェア ラボ キットを参照してください

既知の脅威とソフトウェアの脆弱性のパブリック データベース

ソフトウェアの脅威に関する知識を広げるには、既知の脅威とソフトウェアの脆弱性の使用可能なパブリック データベースを確認します。

• 一般的な脆弱性と露出 (CVE): https://cve.mitre.org/
• 一般的な弱点の列挙: https://cwe.mitre.org/
• 一般的な攻撃パターンの列挙と分類: https://capec.mitre.org/index.html
• NIST は、脆弱性のカタログ化方法を説明するサイトを保持します。 https://samate.nist.gov/BF/

こちらもご覧ください

ドライバーのセキュリティ チェックリスト