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

  • [アーティクル]

ドライバーの作成者と設計者は、あらゆるドライバーの設計プロセスで脅威モデリングを必須にする必要があります。 このトピックでは、Windows ドライバーの脅威モデルを作成するためのガイドラインを示します。

セキュリティは、すべてのドライバーで設計の中心に置かれるべき基本的な要素です。 成功したどのような製品でも標的になります。 Windows 用のドライバーを作成する場合、どこかで、だれかがそのドライバーを使用してシステムのセキュリティ侵害を試みる可能性があると想定する必要があります。

安全なドライバーの設計には、次の作業が含まれます。

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

脅威モデリングは、これらの重要な設計タスクに対する体系化されたアプローチです。 脅威モデルは、資産に対する脅威を分類して分析する手段です。 ドライバー作成者にとっての資産は、コンピューターまたはネットワーク上のハードウェア、ソフトウェア、データです。

脅威モデルは、次のような問いに答えるものです。

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

脅威モデリングは、ソフトウェア設計の重要な要素です。製品にセキュリティを組み込むものであって、事後対策ではないためです。 優れた脅威モデルには、設計プロセス中にバグを発見、防止し、後でコストがかかりがちなパッチや、組織の評判が低下するリスクを排除する効果があります。

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

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

脅威モデルを作成するには、ドライバーの設計、ドライバーがさらされる可能性のある脅威の種類、特定の脅威を悪用するセキュリティ攻撃の影響を十分に理解する必要があります。 ドライバーの脅威モデルを作成すると、潜在的な脅威を軽減する方法が見えてきます。

脅威モデリングは、コーディング中に場当たり的にではなく、ドライバーの設計時に系統的かつ体系的な方法で実施したときに最も効果が発揮されます。 体系的なアプローチを採用することで、設計に潜む脆弱性を発見できる可能性が高まり、モデルの包括性を確保しやすくなります。

脅威モデリング作業を整理する方法の 1 つとして、次の手順があります。

  1. ドライバーを介したデータ フローを示す体系化された図を作成します。 ドライバーによって実行される可能性のあるあらゆるタスクと、ドライバーからのすべての入出力のソースと宛先を含めます。 正式なデータ フロー ダイアグラムまたは同様の体系図は、ドライバーを介したデータのパスを分析し、ドライバーの外部インターフェイス、境界、相互作用を見極めるのに役立ちます。
  2. データ フロー ダイアグラムに基づいて、潜在的なセキュリティ上の脅威を分析します。
  3. 前の手順で特定した脅威を評価し、それらを軽減する方法を判断します。

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

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

Data flow diagram symbols including process, data store, data flow, and external entity.

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

Sample data flow diagram for a hypothetical kernel-mode Windows Driver Model (WDM) driver.

注: 前の図は、ユーザー プロセスとドライバーの間で直接流れるデータを示しており、中間ドライバーは省略されています。 しかし、実際には、すべての要求は、特定のドライバーに到達する前に 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 操作中やデバイス状態の変更中にデバイスに送信されます。

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

Expanded data flow diagram for I/O requests, showing separate tasks for each type of I/O request.

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

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

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

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

モデルは、ドライバーのインストールと更新の手順もカバーしている必要があります。 ドライバーのインストール中に読み取られる、または書き込まれるすべてのファイル、ディレクトリ、レジストリ エントリを加味してください。 また、デバイス インストーラー、共同インストーラー、プロパティ ページで公開されるインターフェイスも考慮しましょう。

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

潜在的な脅威を分析する

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

  • 各リソースを保護するために、どのようなセキュリティ メカニズムが設けられているか。
  • すべての遷移とインターフェイスが適切に保護されているか。
  • 特定の機能を不適切に使用することで、意図せずにセキュリティが侵害される可能性はあるか。
  • 特定の機能が悪意を持って使用された場合にセキュリティが侵害される可能性はあるか。
  • 既定の設定で適切なセキュリティが確保されるか。

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

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

  • なりすまし
  • 改ざん
  • 否認
  • 情報漏えい
  • サービス拒否
  • 権限の昇格

STRIDE をガイドとして使用すると、ドライバーを標的とする攻撃の種類について、細かく問いを設定することができます。 ドライバーの脆弱な各ポイントで発生する可能性がある攻撃の種類を特定し、考えられる攻撃ごとにシナリオを作成するのがその目的です。

  • スプーフィング: 他のだれかの資格情報を使用して、本来アクセスできない資産にアクセスします。 プロセスは、偽造した資格情報や不正に取得した資格情報を渡すことによってスプーフィング攻撃を仕掛けます。

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

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

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

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

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

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

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

ドライバー分析手法

分析を整理する簡単な方法は、脆弱な領域と潜在的な脅威、そして脅威の種類ごとのシナリオを一覧にすることです。

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

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

脆弱なポイント 潜在的な脅威 (STRIDE) シナリオ
IRP_MJ_DEVICE_CONTROL 要求

サービス拒否

権限の昇格

デバイスの障害を引き起こす一連の IOCTL がユーザー プロセスによって発行されます。

FILE_ANY_ACCESS を許可する IOCTL がユーザー プロセスによって発行されます。
ある脅威が別の脅威に関連していることは少なくありません。 たとえば、特権昇格の脅威を悪用する攻撃は、情報の漏えいやサービス拒否につながる可能性があります。 さらに、イベントの順序に依存するタイプの攻撃もあります。 悪意のあるユーザーが最初に着手する可能性があるのは、特権昇格の脅威を悪用することです。 その後、昇格された特権で高まった能力により、ユーザーはさらに別の脆弱性を見つけて悪用する可能性があります。

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

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

Simple threat tree diagram illustrating a hierarchy of threats or vulnerabilities for a denial-of-service scenario.

脅威ツリーには、特定の攻撃を仕掛けるために必要な手順と、手順間の関係が示されます。 脅威ツリーに代わる手段としてアウトラインがあります。

アウトラインは、特定の脅威の攻撃の過程を階層順に一覧にしただけのものです。 次に例を示します。

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 は次の言葉の略です。

  • Damage (損害)
  • Reproducibility (再現性)
  • Exploitability (悪用可能性)
  • Affected user (影響を受けるユーザー)
  • Discoverability (探索可能性)

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

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

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

  • 悪用可能性は、攻撃を仕掛けるために必要な労力と専門知識を評価します。 比較的経験の浅い学生レベルの知識で攻撃できる脅威は、非常に悪用されやすいと言えます。 高度なスキルを持つ要員を必要とし、遂行にコストがかかる攻撃は、悪用される可能性は低くなります。

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

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

  • 探索可能性は、脅威が悪用される可能性です。 探索可能性を正確に見積もるのは困難です。 どのような脆弱性も最終的には悪用されると仮定し、必然的に他の手段を利用して脅威の相対的なランキングを確立するのが最も安全なアプローチです。

サンプル: DREAD を使用して脅威を評価する

次の表は、引き続き前出の例で、設計者が架空のサービス拒否攻撃を評価する方法を示しています。

DREAD 基準 スコア Comments
損害 8 作業を一時的に中断しますが、永続的な損害やデータ損失は発生しない。
再現性 10 デバイスの障害が毎回発生する。
悪用可能性 7 コマンド シーケンスを特定するには重点的な取り組みが必要。
影響を受けるユーザー 10 このデバイスの、市場に流通しているすべてのモデルに影響する。
Discoverability (探索可能性) 10 潜在的な脅威がすべて発見されると考えられる。
合計: 9.0 問題の軽減に向けて高い優先度を持って取り組む必要がある。

脅威を軽減する

モデルによって明らかとなるすべての脅威を軽減するようにドライバーを設計する必要があります。 ただし、軽減策が現実的でない場合もあるでしょう。 たとえば、影響を受けるリスクのあるユーザーがごく少数で、データやシステムの利便性が失われる可能性が低い攻撃を考えてみましょう。 このような脅威を軽減するためだけに数か月の作業が必要な場合、その分の時間をドライバーのテストに費やした方が合理的であると判断できるでしょう。 それでも、最終的には悪意のあるユーザーが脆弱性を見つけて攻撃を仕掛ける可能性があり、そうなれば、ドライバーには問題のパッチが必要になることを覚えておいてください。

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

セキュリティ開発ライフサイクル (SDL: Secure Development Lifecycle) に脅威モデリング プロセスを取り入れることを検討します。

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

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

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

Microsoft は、4 つのコア SDL トレーニング クラスをダウンロード提供しています。 Microsoft Security Development Lifecycle Core Training クラス

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

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

このフェーズの主な出力は、具体的なセキュリティ目標の設定です。 たとえば、すべてのコードが、Visual Studio コード分析の "すべてのルール" に警告件数ゼロで合格するという要件を定めます。

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

ドライバー開発者にとって有益な作業の大半はこのフェーズで行われます。 記述したコードはレビューされ、潜在的な弱点がないか確認されます。 強化できるコード内の領域を探すために、コード分析やドライバー検証ツールなどのツールが使用されます。

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

セキュリティ設計の目標が満たされ、コードを出荷する準備ができていることは、別途 binscope やファズ テスターなどのツールを使用して検証できます。

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

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

行動喚起

以下は、ドライバー開発者を対象としています。

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

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

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

ブック

Writing Secure Code Second Edition (Michael Howard および David LeBlanc 共著)

24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them, First Edition (Michael Howard、David LeBlanc、John Viega 共著)

The art of software security assessment : identifying and preventing software vulnerabilities (Mark Dowd、John McDonald、Justin Schuh 共著)

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

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

Windows セキュリティ モデル: すべてのドライバー作成者が知るべき内容

Microsoft Windows Driver Development Kit (DDK)

カーネルモード ドライバー アーキテクチャのドライバー プログラミング手法を参照してください。

テスト ツール

「パフォーマンスと互換性のテスト」の「Windows Hardware Lab Kit」を参照してください。

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

ソフトウェアの脅威に関する知識を広げるために、公開されているパブリック データベースで、既知の脅威とソフトウェアの脆弱性を確認してください。

参照

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