Trusted Ownership：Ivanti Application Control が許可リストを超えて拡張できる理由

アプリケーション制御は、多くの人が古い思い込みを抱いているセキュリティトピックの一つです。従来の許可リストは安全に見えますが、すぐにメンテナンスの負担になります。ブロックリストは事後対応的で不完全に感じられます。また、Microsoft AppLocker のようなツールによって、厳格な許可リストこそがゴールドスタンダードだと多くの人が考えるようになりましたが、最新の攻撃はそうではないことを証明しています。攻撃者はますます 正規の署名済みツール を不適切なコンテキストで使用し、リストベースの制御を完全に回避するようになっています。

そのため、組織が Ivanti Application Control や Ivanti Neurons for App Control を評価し、Trusted Ownership に出会うと、明示的なブロックが可能であるため、最初はブロックリストに似ているように見えるかもしれません。実際には、Trusted Ownership は、単なる同一性ではなく出所に基づいて実行を制御する、はるかに広範で運用負荷の軽い、プロビナンスに着想を得た強制モデルです。

増え続けるリストを管理するのではなく、システムにソフトウェアを配置した主体に基づいてセキュリティを適用し、最新のソフトウェア配布プラクティスやゼロトラストの原則と自然に整合します。これは、別のリスト機構としてではなく、単なる同一性ではなく出所に基づいて実行を制御する、プロビナンスに着想を得た強制モデルとして理解するのが最適です。

この発想の転換により、最新のアプリケーション制御においてより適切な問いが生まれます。ファイルが何であるかだけでなく、どのようにそこに到達したのか

リストを超えて：プロビナンス制御が今重要な理由

ファイルがどのようにシステムに到達したのかという問いは、プロビナンス制御の中核です。プロビナンス制御では、発行元、パス、ハッシュだけに基づいてファイルを信頼するのではなく、そのファイルを持ち込んだ出所とプロセスを評価します。誰がそのファイルをディスクに書き込んだのか。どの仕組みを通じて行われたのか。インストールは管理された IT ワークフローに従っていたのか。この評価により、アプリケーション制御はオブジェクトの信頼からプロセスの信頼へと移行し、はるかに強固なセキュリティ境界を構築します。

Ivanti Application Control では、プロビナンス制御は Trusted Ownership として実装されています。信頼された所有者が配置したファイルはすべて許可され、ユーザーが持ち込んだものはデフォルトで拒否されます。これは、実行ファイル、DLL、インストーラー、スクリプトに一貫して適用されます。SYSTEM、TrustedInstaller、Administrators などの ID はデフォルトで信頼されるため、MS Intune、MECM、Ivanti Endpoint Manager（EPM）やその他のエンタープライズツールなどの標準的な展開チャネルを通じて提供されるソフトウェアは、ルールのメンテナンスや例外なしですぐに実行されます。

これは、従来の許可リストからの根本的な転換を示しています。AppLocker ルールの成否は、正確な発行元、パス、ハッシュの定義に依存します。インストール元を評価せず、展開メカニズムを自動的に信頼することもありません。Intune で提供されるソフトウェアであっても、事前に許可ルールが必要であり、多くの場合、Program Files や Windows ディレクトリを許可する広範な既定設定に依存します。

この違いが重要なのは、最新の攻撃では、正規のツールが不適切なコンテキストで武器化されるケースが増えているためです。プロビナンス制御は、ソフトウェアがどのように到達したかを信頼の基準として強制し、それが何であるかだけに頼らないことで、そのリスクの多くを無力化します。これはゼロトラストの原則に沿い、サプライチェーンの露出を減らし、Living off the Land（LotL）悪用の機会をデフォルトで大幅に狭めます。

出所の重要性を理解すると、次の問いは「それをどのように大規模に適用するか」です。

答えは、ソフトウェアが実行されるあらゆる方法と、提供されるあらゆる方法に対して、プロビナンスを一貫して適用することです。

ブロックリストを超えて：最新のソフトウェア展開に対応する広範なカバレッジ

プロビナンス制御は、アプリケーションセキュリティを、終わりのないリスト管理から、ソフトウェアがシステムに到達するプロセスの検証へと移行させます。この視点を取り入れると、Trusted Ownership がブロックリスト方式ではないことが明確になります。これは出所に基づく信頼境界であり、従来の許可リストとは大きく異なる動作をします。

Trusted Ownership は、管理者がよく知られた Windows ツールに対して対象を絞った拒否ルールを追加することがあるため、ブロックリストに似ているという誤解があります。実際には、これらの拒否ルールは Living off the Land 技法に対する防御的な強化策です。本格的なアプリケーション制御手法では、いずれもこのような対象を絞った制限を使用します。Trusted Ownership の本質は、ブロックリストの反対です。管理され信頼されたプロセスを通じて提供されたソフトウェアはデフォルトで許可され、ユーザーが持ち込んだコンテンツはデフォルトで拒否されます。

より重要な差別化要因はカバレッジです。従来の許可リストに依存している多くの組織は、ほぼ実行ファイルだけに注力することになりがちです。DLL、スクリプト、MSI パッケージに同じ強制を適用すると、ルールのメンテナンスがはるかに複雑になるため、避けられることが少なくありません。その結果、最新の攻撃者が頻繁に悪用するギャップが生まれます。

Trusted Ownership は、実行チェーン全体に同じ出所ベースの強制を適用することで、こうしたギャップを回避します。実行ファイル、DLL、スクリプト、MSI インストーラー、および関連コンポーネントは、同じ信頼モデルで評価されます。信頼はファイルを持ち込んだ主体によって決まるため、ファイルタイプごとに別個のポリシーを用意する必要はありません。Downloads フォルダー内のスクリプト、一時ビルドディレクトリで作成された DLL、ユーザープロファイルから実行される EXE はいずれも、管理されたインストールプロセスの外部から発生した場合、同じデフォルト拒否の扱いを受けます。

この信頼モデルは、最新のエンドポイント管理プラットフォームがソフトウェアを提供する方法とも自然に整合します。Intune、MECM、Ivanti Neurons for MDM、Ivanti Endpoint Manager などのソリューションや類似システムでは、通常、SYSTEM ID または別の信頼されたサービスアカウントを使用してアプリケーションをインストールします。

これらの ID はすでに Trusted Owners であるため、これらのチャネルを通じて展開されたソフトウェアは、許可ルールの作成、ファイルパスの管理、ポリシーの更新を行わなくてもすぐに実行されます。カスタム DevOps エージェントやユーザーコンテキストでのスクリプトインストールなど、代替のインストールアカウントを意図的に使用する場合にのみ、その ID を Trusted Owner として識別する必要があります。

その結果、関連するすべてのファイルタイプに対して広範で一貫したカバレッジを提供するモデルが実現します。最新のソフトウェア配布とシームレスに連携し、主に実行ファイルに焦点を当てる従来の許可リストに伴う運用オーバーヘッドを回避できます。

Trusted Ownership は、個々のオブジェクトではなく、ソフトウェアが提供される管理されたプロセスを信頼することで、アプリケーション制御に対して、よりスケーラブルでより安全なアプローチを実現します。

WDAC（App Control for Business）の位置付け

Microsoft は、AppLocker と App Control for Business（旧 WDAC）という 2 つのアプリケーション制御テクノロジーを維持しています。どちらも現在も存在していますが、Microsoft はその役割を明確にしています。AppLocker は、ユーザーが未承認のアプリケーションを実行するのを防ぐのに役立ちますが、最新のセキュリティ機能のサービス基準を満たしていないため、戦略的なセキュリティ制御ではなく多層防御メカニズムとして分類されています。

Microsoft がアプリケーション制御の今後の方向性として位置付けているのは App Control for Business であり、AppLocker は機能完了済みで、重要なセキュリティ更新を除いて積極的な開発は行われていないと明示しています。つまり、新機能はすべて WDAC のみに提供され、AppLocker には提供されません。

App Control for Business では、Managed Installer の概念が導入されています。これにより Windows は、Intune や MECM などの指定された展開プラットフォームを通じてインストールされたアプリケーションを自動的に信頼できます。信頼は個々のファイルではなく配布チャネルから導き出されるため、ルールのメンテナンスが大幅に削減されます。

これは、Ivanti Application Control の Trusted Ownership モデルと密接に一致しています。どちらのアプローチも、個別のファイル属性ではなく、ソフトウェアをインストールした管理されたプロセスに基づいてソフトウェアを信頼します。ただし、Trusted Ownership はこの概念をよりシンプルで運用しやすい形で適用します。Ivanti は、複雑なポリシーレイヤー、XML 定義、深い WDAC の専門知識を必要とせずに、SYSTEM や指定されたサービスアカウントなどの ID を信頼します。

Ivanti には、多くの組織が WDAC の運用化に苦労しているという声が寄せられています。WDAC ポリシーには、慎重な設計、監査モードでの長期間のテスト、ドライバーおよびカーネル例外の管理、複数のポリシーセットの継続的なメンテナンスが必要です。そのため、組織は WDAC と AppLocker を組み合わせることが多く、低レベルの強制と日常的なユーザー空間の制御の両方をカバーしようとして、結果的に管理オーバーヘッドを抱えることになります。

Ivanti Application Control は、統合された代替手段を提供します。Trusted Ownership、Trusted Vendors、デジタル署名検証を通じて、実行ファイル、DLL、スクリプト、MSI パッケージにわたって一貫したカバレッジを備えた、プロビナンスベースのデフォルト拒否モデルを実現します。

範囲の異なる 2 つの MS 制御プレーンを維持する代わりに、組織は、ソフトウェアがシステムにどのように導入されたかに基づいて信頼を強制する、単一の合理化されたポリシーを管理します。これにより、WDAC と AppLocker を組み合わせた展開でお客様が達成しようとする実務上の目標の多くを、より低い運用複雑性と一貫した 1 つの信頼モデルで実現できます。

LOLBins と引数レベルの制御

広範なカバレッジが確立されると、次の課題は、攻撃者が悪用しがちな、すべてのマシンにすでに存在する正規のツールをどのように扱うかです。

最新の攻撃者は、従来型のマルウェアの使用を避け、すべての Windows デバイスにすでに存在するツールに依存することがよくあります。これらの Living off the Land ツール（LOLBins）は正規のものであり、通常業務に必要なため、生産性に影響を与えずにブロックすることは困難です。従来の許可リストは、広範にブロックするとワークフローが壊れ、広範に許可すると危険なギャップが残るため、この領域で課題を抱えます。

Trusted Ownership のようなプロビナンスベースのモデルは、この力学を変えます。攻撃者が組み込みツールを使用しようとしても、実行しようとするコンテンツは通常、信頼されたインストールプロセスから来たものではありません。Ivanti はそのコンテンツの出所を評価するため、不正使用の試みの多くは自動的に失敗します。ツール自体は正規のものであっても、実行を求められているコンテンツは正規ではなく、Trusted Ownership は実行前にそれを阻止します。

どのツールが実行されるかだけでなく、それらに何を実行させようとしているのかを理解することも重要です。PowerShell、Python、Java などの多くのインタープリターやランタイムは、あるコンテキストでは完全に安全でも、別のコンテキストではリスクを伴う可能性があります。業務アプリケーションが、特定の承認済みプロセスを開始するために Java に依存している場合と、ユーザーがダウンロードした JAR ファイルの場合とでは、まったく異なるシナリオです。

Ivanti は、階層型のアプローチでこれに対応します。JAR ファイルはまず Trusted Ownership を使用して評価され、管理された展開プロセスではなくユーザーによって持ち込まれたものであれば、直ちにブロックされます。さらに管理者は、許可される Java コマンドを正確に指定するシンプルな許可ルールを作成できるため、正規の Java ベースアプリケーションのみを実行し、未承認の JAR ファイルの起動試行を静かに拒否できます。

同じ原則は、他のツールにも適用されます。ポリシーでは、組織に必要な正確な動作を承認し、その境界を外れるアクティビティをブロックできます。これにより、広範で壊れやすいルールを避けながら、日常業務を円滑に維持できます。

その結果、バランスの取れた最新のアプローチが実現します。Trusted Ownership は、信頼されていないコンテンツをデフォルトで阻止します。重点的な強化は、living off the land の悪用を減らすための政府機関およびコミュニティのベストプラクティスに沿っており、意図を認識する制御により、攻撃者に侵入口を開くことなく正規のプロセスを継続して機能させることができます。

このアプローチは、living off the land 技法の軽減に関する現在のコミュニティおよび政府機関のガイダンスと密接に一致しています。CISA、NSA、FBI、オーストラリアサイバーセキュリティセンター などの機関は、組み込みツールの使用方法を制御し、それらが作用する信頼されていないコンテンツを制限することで、攻撃者が組み込みツールを利用する機会を減らすことを重視しています。共同ガイダンスでは、LOTL 攻撃がネイティブツールの悪用に依存していることを強調し、正規のシステムプロセスをブロックせずにこうした悪用を制限する制御の必要性を訴えています。

Ivanti のモデルは、このガイダンスを反映しています。Trusted Ownership は、攻撃者が依存する信頼されていないコンテンツを自動的にブロックし、少数の重点的な制限によって、追加の注意が必要な少数のツールに対応します。

Trusted Ownership の実践：実際のシナリオ

Ivanti Application Control と Trusted Ownership が実際の運用でどのように機能するかを示す例をいくつか紹介します。

1. ポータブルアプリケーションがユーザープロファイルにコピーされます。Ivanti は、それがユーザー所有であるためブロックします。AppLocker は一致するルールがある場合にのみブロックします。適切なパスまたは発行元ルールがなければ、動作が異なる可能性があります。
2. メール添付ファイルが Downloads から PowerShell スクリプトを起動します。Ivanti はユーザー所有であるため拒否します。AppLocker はスクリプトルールに依存し、ブロックイベント時には PowerShell を制限付き言語モードに強制しますが、それでもスクリプトは実行されます。
3. rundll32 や mshta などの OS ツールの悪用。どちらのモデルでも、対象を絞った拒否による強化が必要です。Ivanti はこれをプロビナンス制御と組み合わせることで、一般的に必要な例外の数を削減します。AppLocker は精選された拒否セットに依存し、定期的な調整が必要です。
4. ベンダーのアップデートによって新しい署名済みファイルが配布されます。Ivanti は、Trusted Ownership により、信頼された展開チャネル経由で到着したアップデートを許可します。AppLocker は発行元ルールでこれに対応できますが、複数製品間での署名の再利用や通常とは異なるインストールパスにより、追加のメンテナンスや意図した以上に広範な信頼につながることがよくあります。
5. ユーザーが JAR をダウンロードし、Java で実行しようとします。Ivanti は、その JAR がユーザーによって持ち込まれ、Trusted Ownership に合格しないため、その試行をブロックします。必要に応じて、管理者は完全なコマンドラインとの照合により、承認済みの正確な呼び出しだけを許可できます。AppLocker は引数を照合できず、発行元、パス、ハッシュのルールに依存します。

まとめ

プロビナンス制御は、アプリケーション制御を管理上の問題から信頼モデルへと移行させます。個々のファイルではなく、ソフトウェアがシステムに到達するプロセスを信頼することで、セキュリティをスケーラブルかつ実運用可能なものにします。

Trusted Ownership は、このアプローチにまさに合致します。これはブロックリストでも従来の許可リストでもなく、管理された IT プロセスを通じて到達したソフトウェアはデフォルトで許可され、そのプロセスの外部にあるものはすべてデフォルトで拒否されるモデルです。場当たり的なファイルではなく、出所と所有権に基づいて強制することで、Ivanti Application Control と Ivanti Neurons for App Control は、最新の攻撃手法や今日のソフトウェア配布とより適切に整合します。

アプリケーション制御をリスト管理の作業として扱い続ければ、管理負担を感じることになります。信頼境界として扱えば、スケーラビリティ、セキュリティ、運用上の実行可能性を得られます。