アプリケーション許可リスト (ホワイトリスト).

アプリケーション許可リスト(かつてのホワイトリスト)は、アンチウイルスの「既定で許可」モデルを反転させます。承認済みポリシーに一致する実行ファイル・DLL・スクリプト・インストーラのみが——ハッシュ・発行元署名・パスのいずれかで——実行を許可され、それ以外はすべてブロックされます。Microsoft AppLocker と Windows Defender Application Control(WDAC)、Linux の fapolicyd、macOS の公証(notarization)ゲート、Airlock Digital や ThreatLocker などの単体製品がこのパターンを実装します。NIST SP 800-167 ガイドがそのアーキテクチャを文書化し、オーストラリア信号総局(ASD)の Essential Eight は、標的型侵入への主要な緩和策の一つとしてアプリケーション制御を挙げています。

難しいのは、明白なマルウェアを止めることではなく、回避手法を塞ぐことです。攻撃者は 現地調達バイナリ(LOLBins)——mshta.exe、regsvr32.exe、msbuild.exe、installutil.exe など Microsoft 署名済みで信頼された正規ツール——を悪用し、ローダが署名済みだという理由で単純な許可リストが信頼してしまうコードを実行します。そのため Microsoft は、こうした既知の回避を無効化する WDAC 向けの 推奨ブロックルール を公開しており、成熟したポリシーは実行ファイルのルールだけでなく DLL・スクリプトのルール も適用して、許可されたプロセスが未署名ライブラリをサイドロードしたり任意スクリプトを実行したりできないようにします。パスベースのルールは最も弱く(ユーザーが書き込める許可フォルダがあれば破られます)、発行元やハッシュのルールはより強力ですが、パッチのたびにハッシュが変わり、新しいツールごとに承認ワークフローが必要になるため、実効的な変更管理が求められます。

flowchart TD
  A[プロセス / DLL / スクリプト<br/>が実行を要求] --> B{許可ポリシーに一致?}
  B -->|ハッシュ一致| C[許可]
  B -->|信頼された発行元署名| C
  B -->|承認済みパス| C
  B -->|一致なし| D[ブロック + ログ]
  C --> E{既知の<br/>LOLBin 回避か?}
  E -->|はい、ブロックルールに該当| D
  E -->|いいえ| F[実行]
  D --> G[アラート / 承認ワークフロー]

「まず監査、次に強制」モードで適切に運用すれば、許可リストはファイルレス攻撃・未署名ランサムウェア・信頼できないダウンロードに極めて有効です。ただし DLL/スクリプトの強制と推奨ブロックルールを有効にした場合に限られ、そうでなければ LOLBins は正面玄関から堂々と入り込みます。