events
11月19日 23時 - 1月10日 23時
Ignite Edition - Microsoft セキュリティ製品のスキルを構築し、1 月 10 日までにデジタル バッジを獲得しましょう。
今すぐ登録このブラウザーはサポートされなくなりました。
Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。
この記事では、Microsoft アプリ ロッカーと Windows Defender アプリケーション コントロールを使用して、オーストラリアのサイバー セキュリティ センター (ACSC) Essential Eight Maturity Model for Application Control を実現するための方法について詳しくは説明します。
アプリケーション制御は、システム上で実行される悪意のあるコードから保護するように設計されたセキュリティ アプローチです。 このセキュリティ アプローチを実装すると、実行可能ファイル、ソフトウェア ライブラリ、スクリプト、インストーラー、ドライバーなどの承認済みコードのみが実行を許可されます。 その有効性により、アプリケーション制御は ACSC の サイバー セキュリティ インシデント軽減戦略の Essential Eight の 1 つです。
アプリケーション制御は、システム上で実行される悪意のあるコードから保護するように設計されたセキュリティ アプローチです。 このセキュリティ アプローチを実装すると、実行可能ファイル、ソフトウェア ライブラリ、スクリプト、インストーラー、ドライバーなどの承認済みコードのみが実行を許可されます。
アプリケーション制御は主に、システムでの悪意のあるコードの実行と拡散を防ぐために設計されていますが、承認されていないアプリケーションのインストールと使用を防ぐこともできます。
アプリケーション制御の実装には、organizationに関する次の大まかな手順が含まれます。
organization内でアプリケーション承認を適用する方法を決定する場合、オーストラリアサイバーセキュリティセンターは、正しく実装された場合に次の方法が適切であると考えられます。
アプリケーション制御は、承認されていないアプリケーションの未承認の実行を防ぐことができます。 アプリケーション制御は、脅威アクターがシステム上で悪意のあるコードを実行しようとする試みの識別にも役立つ可能性があります。 承認された実行と未承認の実行のイベント ログを生成するように WDAC を構成すると、organizationのセキュリティ オペレーション センターに貴重な情報を提供できます。
アプリケーション制御ソリューションは、ウイルス対策やその他のセキュリティ ソフトウェア ソリューションに置き換えられません。 WDAC は常に、Defender ウイルス対策などのウイルス対策ソリューションと連携して動作します。 Microsoft セキュリティ ソリューションを組み合わせて使用すると、システムの侵害を防ぐための効果的な多層防御アプローチに貢献します。
オーストラリアサイバーセキュリティセンターには、Essential8を構成する軽減戦略の成熟度レベルが3つ用意されています。 成熟度レベルは、脅威アクターによって使用される貿易技術のレベルの増加を軽減することに基づいています。 アプリケーション制御のコンテキスト内で、オーストラリアのサイバー セキュリティ センターは、ML 1、2、3 を満たすために必要なものを決定します。
ISM Sep 2024 control | 成熟度レベル | 軽減策 |
---|---|---|
ISM-0109 | 3 | ワークステーションからのイベント ログは、サイバー セキュリティ イベントを検出するためにタイムリーに分析されます。 |
ISM-0140 | 2、3 | サイバー セキュリティ インシデントは、発生または検出された後、できるだけ早く ASD に報告されます。 |
ISM-0123 | 2、3 | サイバー セキュリティ インシデントは、発生または検出された後、できるだけ早く最高情報セキュリティ責任者またはその代理人に報告されます。 |
ISM-0843 | 1, 2, 3 | アプリケーション制御はワークステーションに実装されます。 |
ISM-1490 | 2、3 | アプリケーション制御は、インターネットに接続するサーバーに実装されます。 |
ISM-1656 | 3 | アプリケーション制御は、インターネットに接続されていないサーバーに実装されます。 |
ISM-1544 | 2、3 | Microsoft の推奨されるアプリケーション ブロックリストが実装されています。 |
ISM-1657 | 1, 2, 3 | アプリケーション制御では、実行可能ファイル、ソフトウェア ライブラリ、スクリプト、インストーラー、コンパイル済み HTML、HTML アプリケーション、コントロール パネル アプレットの実行を、organization承認済みのセットに制限します。 |
ISM-1658 | 3 | アプリケーション制御は、ドライバーの実行をorganization承認済みセットに制限します。 |
ISM-1582 | 2、3 | アプリケーションコントロールルールセットは、毎年またはより頻繁に検証されます。 |
ISM-1659 | 3 | Microsoft の脆弱なドライバー ブロックリストが実装されています。 |
ISM-1660 | 2、3 | 許可およびブロックされたアプリケーション制御イベントは、一元的にログに記録されます。 |
ISM-1815 | 2、3 | イベント ログは、未承認の変更と削除から保護されます。 |
ISM-1819 | 2、3 | サイバー セキュリティ インシデントの特定に続いて、サイバー セキュリティ インシデント対応計画が制定されます。 |
ISM-1870 | 1, 2, 3 | アプリケーション制御は、オペレーティング システム、Web ブラウザー、電子メール クライアントで使用されるユーザー プロファイルと一時フォルダーに適用されます。 |
ISM-1871 | 2、3 | アプリケーション制御は、オペレーティング システム、Web ブラウザー、電子メール クライアントで使用されるユーザー プロファイルと一時フォルダー以外のすべての場所に適用されます。 |
ISM-1228 | 2、3 | サイバー セキュリティ イベントは、サイバー セキュリティ インシデントを特定するためにタイムリーに分析されます。 |
ISM-1906 | 2、3 | インターネットに接続するサーバーからのイベント ログは、サイバー セキュリティ イベントを検出するためにタイムリーに分析されます。 |
ISM-1907 | 3 | インターネットに接続していないサーバーからのイベント ログは、サイバー セキュリティ イベントを検出するためにタイムリーに分析されます。 |
ISM Sep 2024 control | 成熟度レベル | Control | Measure |
---|---|---|---|
ISM-0109 | 3 | ワークステーションからのイベント ログは、サイバー セキュリティ イベントを検出するためにタイムリーに分析されます。 | Defender for Endpoint P2 を使用します。 Windows イベント ログは、AMA または Windows 転送イベント ソリューションを介してWindows セキュリティ イベントを使用して、Microsoft SentinelとMicrosoft Defender XDR内でキャプチャされます。 |
ISM-0140 | 2、3 | サイバー セキュリティ インシデントは、発生または検出された後、できるだけ早く ASD に報告されます。 | このドキュメントの範囲外です。 この表の後にメモを参照してください。 3 |
ISM-0123 | 2、3 | サイバー セキュリティ インシデントは、発生または検出された後、できるだけ早く最高情報セキュリティ責任者またはその代理人に報告されます。 | このドキュメントの範囲外です。 この表の後にメモを参照してください。 3 |
ISM-0843 | 1, 2, 3 | アプリケーション制御はワークステーションに実装されます。 | organizationの成熟度レベルの要件に応じて、Windows Defender アプリケーション制御/AppLocker を構成して使用します。 |
ISM-1490 | 2、3 | アプリケーション制御は、インターネットに接続するサーバーに実装されます。 | Windows Defender アプリケーション コントロールを構成して使用する |
ISM-1656 | 3 | アプリケーション制御は、インターネットに接続されていないサーバーに実装されます。 | Windows Defender アプリケーション コントロールを構成して使用する |
ISM-1544 | 2、3 | Microsoft の推奨されるアプリケーション ブロックリストが実装されています。 | Microsoft の "推奨されるブロック 規則" が実装されています |
ISM-1657 | 1, 2, 3 | アプリケーション制御では、実行可能ファイル、ソフトウェア ライブラリ、スクリプト、インストーラー、コンパイル済み HTML、HTML アプリケーション、コントロール パネル アプレットの実行を、organization承認済みのセットに制限します。 | Microsoft では、ファイル発行元ルールまたはファイル ハッシュの定義済みの一覧をアプリケーション制御ポリシー内に作成することをお勧めします。 1 |
ISM-1658 | 3 | アプリケーション制御は、ドライバーの実行をorganization承認済みセットに制限します。 | ハイパーバイザーで保護されたコードの整合性が有効になっており、Windows 11 2022 以降の既定です |
ISM-1582 | 2、3 | アプリケーションコントロールルールセットは、毎年またはより頻繁に検証されます。 | このドキュメントの範囲外です。 この表の下の注を参照してください。 3 |
ISM-1659 | 3 | Microsoft の脆弱なドライバー ブロックリストが実装されています。 | Microsoft の "推奨されるドライバー ブロック規則" が実装されています |
ISM-1660 | 2、3 | 許可およびブロックされたアプリケーション制御イベントは、一元的にログに記録されます。 | Defender for Endpoint P2 を使用します。 Windows イベント ログは、AMA または "Windows 転送イベント" ソリューションを介して "Windows セキュリティ イベント" を使用して、Microsoft SentinelとMicrosoft Defender XDR内でキャプチャされます。 |
ISM-1815 | 2、3 | イベント ログは、未承認の変更と削除から保護されます。 | Microsoft Defender XDRとMicrosoft Sentinelの Role-Based Access Control が適用されます。 |
ISM-1819 | 2、3 | サイバー セキュリティ インシデントの特定に続いて、サイバー セキュリティ インシデント対応計画が制定されます。 | このドキュメントの範囲外です。 この表の下の注を参照してください。 3 |
ISM-1870 | 1, 2, 3 | アプリケーション制御は、オペレーティング システム、Web ブラウザー、電子メール クライアントで使用されるユーザー プロファイルと一時フォルダーに適用されます。 | Microsoft では、ファイル発行元ルールまたはファイル ハッシュの定義済みの一覧をアプリケーション制御ポリシー内に作成することをお勧めします。 成熟度レベル 1 は、Microsoft AppLocker で実現できます。 成熟度レベル 2 と 3 には、Windows Defender アプリケーション制御が必要です。 2 |
ISM-1871 | 2、3 | アプリケーション制御は、オペレーティング システム、Web ブラウザー、電子メール クライアントで使用されるユーザー プロファイルと一時フォルダー以外のすべての場所に適用されます。 | Windows Defender アプリケーション コントロールの実装と構成 |
ISM-1228 | 2、3 | サイバー セキュリティ イベントは、サイバー セキュリティ インシデントを特定するためにタイムリーに分析されます。 | このドキュメントの範囲外です。 この表の後にメモを参照してください。 3 |
ISM-1906 | 2、3 | インターネットに接続するサーバーからのイベント ログは、サイバー セキュリティ イベントを検出するためにタイムリーに分析されます。 | Defender for Endpoint P2 を使用します。 Windows イベント ログは、AMA または Windows 転送イベント ソリューションを介してWindows セキュリティ イベントを使用して、Microsoft SentinelとMicrosoft Defender XDR内でキャプチャされます。 |
ISM-1907 | 3 | インターネットに接続していないサーバーからのイベント ログは、サイバー セキュリティ イベントを検出するためにタイムリーに分析されます。 | Defender for Endpoint P2 を使用します。 Windows イベント ログは、AMA または Windows 転送イベント ソリューションを介してWindows セキュリティ イベントを使用して、Microsoft SentinelとMicrosoft Defender XDR内でキャプチャされます。 |
重要
1 ISM-1657 を満たすために、Microsoft では、アプリケーション制御ポリシー内にファイル発行元規則またはファイル ハッシュの定義済みの一覧が作成されていることをお勧めします。 ファイル パス規則を利用しすぎる場合、organizationは、ユーザーがフォルダーとファイルのアクセス許可、フォルダーの内容、および個々のファイルの不正な変更を防ぐことを確認する必要があります。 たとえば、ユーザーは NTFS 内のファイル パス 規則の場所への書き込みアクセス権を持つべきではありません。
2 ISM-1870 を満たすために、Microsoft では、アプリケーション制御ポリシー内にファイル発行元規則またはファイル ハッシュの定義済みの一覧が作成されていることをお勧めします。 成熟度レベル 1 は、Microsoft AppLocker で実現できます。 成熟度レベル 2 と 3 には、追加の ISM 要件があるため、Windows Defender アプリケーション制御の要件があります。 ISM-1870 では、ユーザーのプロファイルと一時フォルダー内にファイル システム権限があるため、ファイル パス規則は推奨されません。
3 コントロール ISM-0140、0123、1582、1819、1228 は、明示的に主要なユーザーとプロセス コントロールです。 Microsoft では、Essential 8 コンプライアンス レビューの自動化されたテクノロジ証拠の一部として、ユーザーとプロセスを文書化し、 Purview コンプライアンス マネージャーのアーティファクトとして保存することをお勧めします。
Microsoft では、AppLocker ではなく Windows Defender アプリケーションコントロール (WDAC) を実装することをお勧めします。 Windows Defender アプリケーションコントロールは継続的に改善されています。 AppLocker は引き続きセキュリティ修正プログラムを受け取りますが、機能の改善は受け取りません。
ただし、一部のユーザーが特定のアプリケーションを実行できないようにすることが重要な共有デバイスなどのシナリオでは、AppLocker を Windows Defender アプリケーション制御の補完として展開することもできます。 Microsoft では、organizationでは、organizationで可能な限り最も制限の厳しいレベルとして Windows Defender アプリケーション制御を適用し、必要に応じて AppLocker を使用してユーザー モードの制限をさらに微調整することをお勧めします。
ヒント
WDAC をお勧めしますが、ほとんどの組織では、出発点として AppLocker だけを使用して ML1 を実現する方が簡単で簡単ですが、どちらのソリューションも無料です。
AppLocker は Windows 7 で導入され、organizationは、Windows オペレーティング システムで実行できるユーザー モード (アプリケーション) プロセスを制御できます。 AppLocker ポリシーは、システム上のすべてのユーザー、または次に基づいて定義できるルールを持つ個々のユーザーとグループに適用できます。
AppLocker ポリシーは、サポートされている任意のバージョンと Windows オペレーティング システムの追加で作成でき、グループ ポリシー、PowerShell、または Mobile デバイス管理 ソリューションを使用して展開できます。
Windows Defender アプリケーションコントロール (WDAC) は、Windows 10で導入されました。 これにより、組織は、Windows オペレーティング システムで実行できるユーザー モード (アプリケーション) プロセスとカーネル モード (ドライバー) プロセスを制御できます。 WDAC ポリシーはマネージド システム全体に適用され、次に基づいて定義できる規則を持つデバイスのすべてのユーザーに影響します。
WDAC ポリシーは、サポートされている任意のクライアント エディションのWindows 10、Windows 11、または Windows Server 2016 以上で作成できます。 WDAC ポリシーは、グループ ポリシー、モバイル デバイス管理 ソリューション、Configuration Manager、または PowerShell を使用して展開できます。
Microsoft のサービスとしての Windows では、新しい機能の開発と展開をお客様に許可するため、WDAC の一部の機能は特定の Windows バージョンでのみ使用できます。
Windows Defender アプリケーション制御と Applocker の詳細については、「 Windows Defender アプリケーション制御と AppLocker 機能の可用性」を参照してください。
管理者がユーザー ベースのアプリケーション制御用の AppLocker ポリシーを展開する場合、パスベースの実装のサンプルとして次の規則を使用できます。 これには、ルール、規則の適用、アプリケーション ID サービスの自動開始が含まれます。
推奨される方法は、次のパスを (最小限で) ブロックすることです。
ML1 での AppLocker の詳細については、次の記事を参照してください。
Microsoft AppLocker ポリシーは、いくつかの方法を使用して作成できます。 Microsoft では、AppLocker ポリシーの作成を支援するために、Microsoft オープン ソース プロジェクト AaronLocker を使用することをお勧めします。 AaronLocker を使用すると、PowerShell スクリプトのサービスを使用して、AppLocker の堅牢で厳格なアプリケーション制御を可能な限り簡単かつ実用的に作成およびメンテナンスできます。 AaronLocker は、管理者以外のユーザーによるプログラムとスクリプトの実行を制限するように設計されています。
Aaronlocker の詳細については、「 AaronLocker: Windows の堅牢で実用的なアプリケーション制御」を参照してください。
Microsoft AppLocker は、Microsoft Intune、グループ ポリシー、または PowerShell を使用して展開できます。 デプロイ方法は、organizationの現在の管理ソリューションに依存します。
アプリ ロッカーの展開の詳細については、次の記事を参照してください。
Microsoft AppLocker 関連のイベントは、Microsoft のSentinelなどのセキュリティ情報とイベント管理ソリューションによって監視されます。 イベントは、Microsoft Defender for Endpointの高度なハンティング情報を使用して監視することもできます。
Microsoft Defender for Endpoint: AppLocker リファレンス
Microsoft Defender for Endpointは、Microsoft AppLocker に関連して次のイベントをキャプチャします。
ActionType 名 | イベント ソース ID |
---|---|
AppControlExecutableAudited | 8003 |
AppControlExecutableBlocked | 8004 |
AppControlPackagedAppAudited | 8021 |
AppControlPackagedAppBlocked | 8022 |
AppControlPackagedAppBlocked | 8006 |
AppControlScriptBlocked | 8007 |
AppControlCIScriptAudited | 8001 |
イベント ビューアーと高度なハンティングの詳細については、次の記事を参照してください。
Microsoft では、WDAC を使用した Essential Eight アプリケーション制御 ML2 と ML3 を満たすために、設計プロセス、ライフサイクル管理、デプロイ、運用ガイダンスについて説明しています。
Essential Eight Application Control ML1 の要件をお持ちのお客様は、Microsoft AppLocker を使用して実現できます。
このガイダンスを使用するための前提条件は次のとおりです。
Windows Server オペレーティング システム上の WDAC は、このガイドの範囲外です。 Windows Server のガイダンスは、今後のリリースで提供される予定です。
M365 関連のサービスは、必要なサービス、価値提案、ライセンス要件を理解するために、Microsoft 365 および Office 365 サービスの説明内に配置できます。
Microsoft 365 および Office 365 サービスの説明
WDAC に関連付けられている製品の詳細については、次の記事を参照してください。
organizationが WDAC の計画を開始すると、設計上の決定事項を考慮すると、ポリシーの展開とアプリケーション制御ポリシーのメンテナンスにどのように影響するかが決まります。
次のことが当てはまる場合は、WDAC をorganizationのアプリケーション制御ポリシーの一部として使用する必要があります。
WDAC には、"信頼の輪" という概念が組み込まれています。 各organizationには、ビジネス要件に固有の "信頼の輪" の定義が異なります。 ACSC Essential 8 関連の定義は ISM コントロール 1657 です。"アプリケーション制御では、実行可能ファイル、ソフトウェア ライブラリ、スクリプト、インストーラー、コンパイル済み HTML、HTML アプリケーション、コントロール パネル アプレットの実行がorganization承認済みセットに制限されます。
Microsoft では、%OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies の下にある XML 形式内のいくつかのポリシー例を提供しています。 Microsoft のポリシー例では、organizationを既存の基本ポリシーから開始し、必要に応じてルールを追加または削除してカスタム ポリシーを構築できます。
ポリシー設計の詳細については、次の記事を参照してください。
WDAC では、次の 2 つのポリシー形式がサポートされています。
単一ポリシー形式: RTM とWindows Server 2016 Windows 10使用してリリースされた元のポリシー形式。 単一ポリシー形式では、特定の時点でシステム上の 1 つのアクティブ なポリシーのみがサポートされます
複数のポリシー形式 (推奨): このポリシー形式は、Windows 10 1903 以降、Windows 11、および Windows Server 2022 でサポートされています。 複数のポリシー形式を使用すると、Windows Defender アプリケーションコントロールを展開するための柔軟性が向上し、デバイスで最大 32 個のアクティブなポリシーがサポートされます。 さらに、次のシナリオが可能になります。
Microsoft では、複数のポリシー形式を使用し、明確に定義されたシナリオや、Windows Server 2016や Windows Server 2019 などの複数のポリシー形式を使用できない場合にのみ、単一のポリシー形式を使用することをお勧めします。
WDAC 制御ポリシーの詳細については、「 複数の Windows Defender アプリケーション制御ポリシーを使用する」を参照してください。
WDAC には、次の 2 つの概念が含まれています。
ポリシールールとファイルルールの詳細については、次の記事を参照してください。
PowerShell または WDAC ウィザードを使用して WDAC ポリシーを作成するには、主に 2 つの方法があります。
ポリシーの作成の詳細については、次の記事を参照してください。
Microsoft では、Essential Eight for Application Control を実装するための Windows Defender アプリケーション制御ウィザードの使用をお勧めします。 または、サンプル ポリシーをベースとして使用するか、参照システムから適切に定義されたシナリオのポリシーを作成したい場合に、DevOps 運用モデルの高度な要件を持つ組織で PowerShell を使用することもできます。
organizationがアプリケーション制御ソリューションの実装を開始する前に、ポリシーの管理方法と管理方法を時間の経過と同時に考慮する必要があります。 ほとんどの WDAC ポリシーは時間の経過と共に進化し、有効期間中に一連の識別可能なフェーズを継続します。 これらのフェーズは次のとおりです。
WDAC ポリシーを効果的に管理するには、ポリシー XML ドキュメントを中央リポジトリに格納して管理する必要があります。 Microsoft では、GitHub などのソース管理ソリューションや、バージョン管理を提供する SharePoint などのドキュメント管理ソリューションをお勧めします。
このセクションでは、PowerShell と Microsoft Intune を使用して WDAC マネージド インストーラーを構成する要件に関するお客様のガイダンスを提供することを目的としています。
注意
このサンプル スクリプトでは AppLocker が使用されていないため、手順 1 では 問題のない DENY 規則 は存在しません。 AppLocker のこの構成は、マネージド インストーラーを必要とするすべてのデバイスに対して作成されます。
次に、Intune管理拡張機能 - PowerShell スクリプトを使用してデプロイできるスクリプトの例を示します。
$ScriptDir = Split-Path $script:MyInvocation.MyCommand.Path
$AppLockerMIPolicy =
@"
<AppLockerPolicy Version="1">
<RuleCollection Type="ManagedInstaller" EnforcementMode="Enabled">
<FilePublisherRule Id="55932f09-04b8-44ec-8e2d-3fc736500c56" Name="MICROSOFT.MANAGEMENT.SERVICES.INTUNEWINDOWSAGENT.EXE version 1.39.200.2 or greater in MICROSOFT® INTUNE™ from O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
<Conditions>
<FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="MICROSOFT.MANAGEMENT.SERVICES.INTUNEWINDOWSAGENT.EXE">
<BinaryVersionRange LowSection="1.39.200.2" HighSection="*" />
</FilePublisherCondition>
</Conditions>
</FilePublisherRule>
<FilePublisherRule Id="6ead5a35-5bac-4fe4-a0a4-be8885012f87" Name="CMM - CCMEXEC.EXE, 5.0.0.0+, Microsoft signed" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
<Conditions>
<FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="CCMEXEC.EXE">
<BinaryVersionRange LowSection="5.0.0.0" HighSection="*" />
</FilePublisherCondition>
</Conditions>
</FilePublisherRule>
<FilePublisherRule Id="8e23170d-e0b7-4711-b6d0-d208c960f30e" Name="CCM - CCMSETUP.EXE, 5.0.0.0+, Microsoft signed" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
<Conditions>
<FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="CCMSETUP.EXE">
<BinaryVersionRange LowSection="5.0.0.0" HighSection="*" />
</FilePublisherCondition>
</Conditions>
</FilePublisherRule>
</RuleCollection>
</AppLockerPolicy>
"@
$AppLockerMIPolicy | Out-File -FilePath $ScriptDir\AppLockerMIPolixy.xml
Set-AppLockerPolicy -XmlPolicy $ScriptDir\AppLockerMIPolixy.xml -Merge -ErrorAction SilentlyContinue
Start-Process -FilePath "$env:windir\System32\appidtel.exe" -ArgumentList "start -mionly" | Wait-Process
Remove-Item -Path $ScriptDir\AppLockerMIPolixy.xml
重要
管理者は、ハッシュまたはパブリッシャーを使用して、WDAC ファイル規則ポリシーに構成スクリプトを追加する必要があります。
WDAC のマネージド インストーラーと呼ばれる機能により、アプリケーション制御ポリシーを適用するときに、セキュリティと管理性のバランスを取るためのorganizationが可能になります。 これにより、アプリケーションをMicrosoft Configuration ManagerやIntuneなどのソフトウェア配布ソリューションによってインストールできます。
一般的な誤解は、WDAC のポリシー内で "マネージド インストーラー" ルールを構成することだけです。 これは正しくありません。この機能を動作させるためには、AppLocker の別の構成が必要です。
マネージド インストーラーでは、AppLocker 内の規則コレクションを使用して、アプリケーションのインストールのためにorganizationによって信頼されるバイナリを指定します。 Windows は、構成されたバイナリのプロセスを監視し、ディスクに書き込まれる関連ファイルを監視しながら起動する子プロセスを監視します。 これらのファイルは、マネージド インストーラーから生成されたタグとしてタグ付けされているため、実行が許可されます。
GPO Edit 内での AppLocker ポリシーの作成と AppLocker PowerShell コマンドレットを直接使用して、マネージド インストーラー コレクションのルールを作成することはできません。 VS Code または別のエディター ツールを使用して、マネージド インストーラー規則コレクションを作成する必要があります。
AppLocker 構成サービス プロバイダー (CSP) は現在、マネージド インストーラー規則のコレクションの種類をサポートしていないため、AppLocker ポリシーは、Microsoft Intuneの PowerShell を使用してイングレスである必要があります。
ISM-1657 を満たすには Windows Defender アプリケーション コントロールの機能 "スクリプトの適用" が必要であるため、PowerShell、VBscript、cscript、cscript、HSMTA、MSXML を制御するには、スクリプトの適用が必要です。 "マネージド インストーラー" を構成する PowerShell スクリプトは、ハッシュまたはパブリッシャーを使用して WDAC ファイル ポリシー規則内にある必要があります。
Microsoft では、Microsoft Intuneのマネージド インストーラーの構成をお勧めします。 Intuneを使用すると、Windows Defender アプリケーション制御ポリシーを頻繁に更新する必要なく、Microsoft Intuneを使用してパッケージ化されたアプリケーションを堅牢に管理できます。
マネージド インストーラーに対するこの構成スクリプトのデプロイは、シナリオに応じて、Microsoft Intuneを使用して 2 つの方法で実現できます。
PowerShell スクリプトのデプロイの詳細については、次の記事を参照してください。
オプションを理解し、決定を設計すると、organizationは Windows Defender アプリ制御ウィザードを使用して最初の監査ポリシーを作成できます。
Windows Defender アプリコントロール ウィザードを開き、[ポリシー作成者] を選択します。
[ポリシー作成者] で、[複数のポリシー形式] と [基本ポリシー] を選択し、[次へ] を選択します。
ポリシー テンプレート内には、次の 3 つのオプションが表示されます。
重要
Reputation-Based アプリケーション制御用インテリジェンスは、要件 "組織が承認したセット" (ISM 1657) と "アプリケーション制御ルール セットは年単位または頻度の高い基準で検証される" (ISM 1582) のため、Essential8 アプリケーション制御を満たしていません。WDAC 内のこの機能は、ML2 または ML3 の要件を満たしていません。 Microsoft では、Essential8 アプリケーション コントロールのコンテキスト外で WDAC を採用する組織に対して、Reputation-Based インテリジェンスを使用することをお勧めします。
注意
WDAC – ポリシー規則の詳細については 、こちらを参照してください。
注意
その他のすべての WDAC ポリシー規則は、organization内の要件に依存します。
Windows Defender アプリコントロール ウィザードでは、次の情報が生成されます。
WDAC – ポリシー規則の詳細については 、こちらを参照してください。
注意
Windows Defender アプリコントロール ウィザードを使用して生成された各ポリシーは、新しいグローバル一意識別子 (GUID) を取得します。
WDAC ポリシーが正常に作成されました。
organizationが WDAC ウィザードを使用して WDAC ポリシーを作成すると、organizationはテキスト エディター内でこのファイルのコンテキストを表示できます。 XML は、Essential Eight のコンテキストで PolicyID と BasePolicyID をメモするために、いくつかの異なるセクションに分割されます。
注意
ポリシー XML を直接編集することもできます。 Microsoft では、PowerShell の Windows Defender アプリコントロール ウィザードまたは構成可能なコード整合性コマンドレットを使用して、ポリシー 規則または署名ファイルに対するすべての追加の変更を行うことをお勧めします。
organizationで監査ポリシーが作成されたので、Intuneデバイス管理を使用して展開します。
注意
この情報は、上記のセクションの "監査ポリシーの作成" から作成されたポリシー XML の Windows >Defender アプリ制御ウィザードから生成されたポリシー ID に依存します。
- Name = Microsoft Allow Audit
- OMA-URL = ./Vendor/MSFT/ApplicationControl/Policies/CB46B243-C19C-4870-B098-A2080923755C/Policy
- データ型 = Base64 (ファイル)
WDAC ポリシーのライフサイクルに従って、organizationは "Microsoft 監査を許可する" ポリシーから生成されたイベントを確認する必要があります。 WDAC 監査ポリシーの監視は、次の 2 つの方法で実現できます。
イベント ID の詳細については、「 Application Control イベント ID について - Windows セキュリティ」を参照してください。
Microsoft では、Microsoft Defender XDR (MDE) 統合を使用してMicrosoft Sentinelすることをお勧めします。 MDEとSentinelを使用すると、高度なハンティング テレメトリ データを、Microsoft Defender for Endpointと比較して 30 日間以上保存できます。
接続と監視の詳細については、次の記事を参照してください。
次の例では、ユーザーが、organizationの毎日のタスクに使用される複数のアプリケーションを持つ例を示します。 この例には、Microsoft アプリケーションとさまざまなオープンソース アプリケーションの両方が含まれています。
この例は強制 監査モードであるため、管理者は 、WinSCP、VLC、Putty、FileZilla に対してトリガーされたイベントが、これらのアプリケーションが初期監査ポリシーの一部ではないために表示されます (ただし、ユーザーには影響しません)。
次に、Microsoft Defender ポータルを使用して、「Advanced Hunting」と入力して監査イベントを絞り込み、監査モードが無効になっている場合に発生する予期しないブロックや不要なブロックを把握し、この例で強制モードにします。
前のページの参照スキーマを使用して、過去 7 日間の WDAC によってトリガーされたすべてのポリシー監査イベントを探し、キーボード クエリ言語 (KQL) クエリの例を使用して関連情報を表示します。
DeviceEvents
| where ActionType startswith "AppControlCodeIntegrityPolicyAudited"
| where Timestamp > ago(7d)
| project DeviceId, // The device ID where the audit block happened
FileName, // The audit blocked app's filename
FolderPath, // The audit blocked app's system path without the FileName
InitiatingProcessFileName, // The file name of the parent process loading the executable
InitiatingProcessVersionInfoCompanyName, // The company name of the parent process loading the executable
InitiatingProcessVersionInfoOriginalFileName, // The original file name of the parent process loading the executable
InitiatingProcessVersionInfoProductName, // The product name of the parent process loading the executable
InitiatingProcessSHA256, // The SHA256 flat hash of the parent process loading the executable
Timestamp, // The event creation timestamp
ReportId, // The report ID - randomly generated by MDE AH
InitiatingProcessVersionInfoProductVersion, // The product version of the parent process loading the executable
InitiatingProcessVersionInfoFileDescription, // The file description of the parent process loading the executable
AdditionalFields // Additional fields contains FQBN for signed binaries. These contain the CN of the leaf certificate, product name, original filename and version of the audited binary
前の KQL クエリを使用した出力の例を次に示します。
レコード内には、プロセス ツリー、ファイル パス、SHA 情報、署名者、発行者情報などの情報の詳細なレポートがあります。
次の手順では、結果を絞り込みます。
同じ KQL クエリを使用して、開始プロセス ファイル名が Windows エクスプローラーである別のフィールドを追加します。 KQL クエリには、GUI 内のユーザーによって実行されたアプリケーションが表示されます。
DeviceEvents
| where ActionType startswith "AppControlCodeIntegrityPolicyAudited"
| where Timestamp > ago(7d)
| where InitiatingProcessFileName startswith "explorer.exe" // Users starting an Application via File Explorer / GUI
| project DeviceId, // The device ID where the audit block happened
FileName, // The audit blocked app's filename
FolderPath, // The audit blocked app's system path without the FileName
InitiatingProcessFileName, // The file name of the parent process loading the executable
InitiatingProcessVersionInfoCompanyName, // The company name of the parent process loading the executable
InitiatingProcessVersionInfoOriginalFileName, // The original file name of the parent process loading the executable
InitiatingProcessVersionInfoProductName, // The product name of the parent process loading the executable
InitiatingProcessSHA256, // The SHA256 flat hash of the parent process loading the executable
Timestamp, // The event creation timestamp
ReportId, // The report ID - randomly generated by MDE AH
InitiatingProcessVersionInfoProductVersion, // The product version of the parent process loading the executable
InitiatingProcessVersionInfoFileDescription, // The file description of the parent process loading the executable
AdditionalFields // Additional fields contains FQBN for signed binaries. These contain the CN of the leaf certificate, product name, original filename and version of the audited binary
前の KQL クエリを使用した出力の例を次に示します。
KQL クエリ アクションにより、情報がより管理データセットに絞り込まれるようになりました。 見ることができるのは、目的のシステムで使用されているアプリケーションです。 これらのアプリケーションは、organizationのポリシーに追加するか、組織の変更制御を使用して追加する必要があります。
注意
KQL は、非構造化データセットと構造化データセットを表示するための強力なツールです。 これは KQL の使用例に過ぎ、Microsoft では次のドキュメントを確認することをお勧めします。詳細なハンティング クエリ言語については、Microsoft Defender XDR
KQL を使用して検索結果を絞り込んだ後、次の手順は WDAC 基本ポリシーを更新するか、補足ポリシーを使用することです。 次の例では、補足ポリシーを使用します。
Windows Defender アプリ制御ウィザードを開き、[ポリシー作成者] を選択します。
[ポリシー作成者] で、[複数のポリシー形式] と [補足ポリシー] を選択し、基本ポリシーに移動し、場所を更新して補足ポリシーを保存し、[次へ] を選択します。
[ポリシー ルール] で [次へ] を選択します。
[ ポリシー署名規則] で、[ カスタム 規則] を選択します。
カスタム ルール条件内では、次のような多くのオプションを使用できます。
注意
Microsoft では、必要に応じてパブリッシャー ベースのルールを使用し、署名されていない参照ファイルに対してハッシュ ベースの規則にフォールバックして、Essential8 アプリケーション コントロールを実装することをお勧めします。
Microsoft Defender for Endpointの使用
注意
Microsoft では、発行元ベースの規則を作成するために、CA、Publisher を 少なくとも 選択的に発行することをお勧めします。 製品名は含めることができます。発行元ベースの規則については ACSC によって推奨されます。
ポリシーを適用するように切り替えるには:
Windows Defender アプリ制御ウィザードを開き、[ポリシー エディター] を選択します。
適用に変更するポリシー XML に移動します。
ポリシー ルール内で監査モードスイッチを無効にします。
[ポリシー ルール] で [次へ] を選択します。
更新ポリシーが修正されたバージョン番号で作成され、新しい CIP ファイルが作成されました。
Microsoft Endpoint Manager 管理 Center 内で、[デバイス]、[構成プロファイル] の順に移動します。
次に、プロファイル、プラットフォーム - Windows 10以降、プロファイルの種類テンプレートとカスタムを作成します。
ポリシーの名前 (アプリケーション制御 – ポリシーの適用など) を作成し、[ 次へ] を選択します。
[ OMA-URI 設定] で、[ 追加] を選択します。
注意
この情報は、上記の監査の作成セクションから作成されたポリシー XML の Windows Defender アプリ制御ウィザードから生成されたポリシー ID に依存します。
- Name = Microsoft Allow Enforce
- OMA-URL = ./Vendor/MSFT/ApplicationControl/Policies/CB46B243-C19C-4870-B098-A2080923755C/Policy
- データ型 = Base64 (ファイル)
Windows Defender アプリコントロール ウィザードによってポリシー XML が生成されると、(GUID) も作成されます。CIP ファイル。 次の手順では、この CIP ファイルをコピーし、ファイル拡張子の名前を に変更します。BIN (例: {CB46B243-C19C-4870-B098-A2080923755C}.bin。
Base64 (ファイル) の下に BIN をアップロードします。
[保存] を選択します。
プロンプトに従って 構成プロファイルを作成します。
アプリケーション制御の展開 – 目的のシステムにポリシー構成プロファイルを適用します。
注意
管理者は、以前に作成したアプリケーション – 監査ポリシーを、適用するように切り替えられる目的のシステムから除外する必要があります
events
11月19日 23時 - 1月10日 23時
Ignite Edition - Microsoft セキュリティ製品のスキルを構築し、1 月 10 日までにデジタル バッジを獲得しましょう。
今すぐ登録トレーニング
モジュール
適応型アプリケーション制御を使用してアプリケーションの許可リストを作成して実装する - Training
組織内に適応型アプリケーション制御を実装して、Windows Server IaaS VM を保護することができます。
認定資格
Microsoft 認定: Information Protection and Compliance Administrator Associate - Certifications
Microsoft 365 デプロイを保護するためのデータ セキュリティ、ライフサイクル管理、情報セキュリティ、コンプライアンスの基礎を示します。