ASRルールを業務ソフトやマクロへの影響が分からないまま有効化する場合は、最初から全端末をBlockにしてはいけません。まず、代表的なテスト端末だけをAuditに設定します。AuditではASRルールに該当する操作を記録しますが、その操作自体はブロックされません。
収集したイベントをルール、実行ファイル、操作内容ごとに確認し、正当な業務に必要なものだけへ限定的な例外を設定します。その後、ルール単位でBlock、または対応している場合はWarnへ段階的に移行するのが基本です。Microsoftも、小規模なパイロットグループからAuditで検証し、影響を評価してから展開範囲を広げる方法を案内しています。([Microsoft Learn][1])
ASRルールは「マクロをすべて禁止する機能」ではない
ASRはAttack Surface Reductionの略で、Microsoft Defender Antivirusが、攻撃で悪用されやすいソフトウェアの動作を制御する機能です。
たとえば、次のような動作が対象になります。
- OfficeアプリからコマンドプロンプトやPowerShellを起動する
- VBAマクロからWin32 APIを呼び出す
- Officeアプリから実行可能なファイルを作成する
- Officeアプリから別のプロセスへコードを挿入する
- 難読化されたスクリプトを実行する
問題になるのは、攻撃者が使う動作と、正当な業務ソフトが使う動作が重なることです。古い業務ソフトや高度なExcelマクロでは、外部プログラムの起動、API呼び出し、一時ファイルの生成などが組み込まれていることがあります。ASRルールはアプリ名だけでなく動作を評価するため、単に「Excelマクロを使用している」という情報だけでは影響を判断できません。([Microsoft Learn][2])
業務ソフトやマクロで確認したい代表的な操作
| 業務上の操作 | 関係しやすいASRルール | 確認するポイント |
|---|---|---|
| ExcelやWordからPowerShell、cmd、別の業務ソフトを起動する | Officeアプリケーションによる子プロセスの作成をブロック | 外部プログラムを起動するマクロやアドインがないか |
| VBAからWindows APIを呼び出す | OfficeマクロからのWin32 API呼び出しをブロック | API宣言を使ったファイル操作、画面制御、外部連携がないか |
| マクロがEXE、DLL、スクリプトなどを保存・実行する | Officeアプリケーションによる実行可能コンテンツの作成をブロック | 一時フォルダーへの出力や補助プログラムの展開がないか |
| Officeから別プロセスへコードを挿入する | Officeアプリケーションによる他プロセスへのコード挿入をブロック | 古いアドインや特殊な連携製品が使用していないか |
| WMIやPSExecを使って別端末で処理を実行する | PSExecおよびWMIコマンドに起因するプロセス作成をブロック | 管理ツール、資産管理、配布処理への影響がないか |
たとえば「Officeアプリケーションによる子プロセスの作成をブロック」は、Word、Excel、PowerPoint、OneNote、Accessなどからの子プロセス作成を対象とします。Microsoftも、正当な業務アプリがコマンドプロンプトやPowerShellを起動する場合があると説明しています。([Microsoft Learn][3])
Audit・Warn・Blockの違い
ASRルールを安全に導入するには、各モードの違いを正しく理解する必要があります。
| モード | 動作 | 主な用途 |
|---|---|---|
| Audit | ルールに該当する操作を記録するが、ブロックしない | 業務影響の調査、例外候補の確認 |
| Warn | Block相当の制御を行い、条件を満たせば一時的な解除手段を提供する | Blockへ移行する前の段階展開 |
| Block | ルールに該当する操作を実際にブロックする | 本番運用 |
| Not configured | ルールを明示的に有効化しない | 未展開のルール、ポリシー整理 |
| Off | ルールを明示的に無効化する | 原則として限定的な用途 |
Auditは「検知だけを行うモード」です。業務を止めずに影響候補を収集できる一方、ASRルールによる防御も実行されません。そのため、Auditのまま長期間放置するのではなく、調査後にBlockやWarnへ進める必要があります。
Warnは単なる通知モードではありません。基本的にはBlockとして動作し、一時的な解除機能が付加されます。解除方法にはOS、Microsoft Defender Antivirusのバージョン、管理方法などの要件があります。現在のMicrosoft Defender Antivirusプラットフォームでは、Warnの解除に管理者承認が必要とされています。
また、すべてのASRルールがWarnに対応しているわけではありません。Microsoftの資料では、「Windowsローカルセキュリティ機関サブシステムからの資格情報の盗難をブロック」と「Officeアプリケーションによる他プロセスへのコード挿入をブロック」はWarn非対応とされています。Warnを設定する前に、対象ルールの最新仕様を確認してください。([Microsoft Learn][2])
ASRルールを有効化する前の確認事項
Microsoft Defender Antivirusが有効か確認する
ASRルールを利用するには、Microsoft Defender Antivirusがアクティブモードで動作し、リアルタイム保護が有効になっている必要があります。
他社製ウイルス対策ソフトの導入によってMicrosoft Defender Antivirusがパッシブモードになっている環境では、ASRルールが想定どおり動作しない可能性があります。Microsoftはクラウド提供の保護もASRの重要な構成要素として挙げています。([Microsoft Learn][2])
確認する項目は次のとおりです。
- Microsoft Defender Antivirusがアクティブモードか
- リアルタイム保護が有効か
- セキュリティインテリジェンスやプラットフォームが更新されているか
- クラウド提供の保護が利用できる状態か
- 対象端末がMicrosoft Defender for Endpointへオンボードされているか
ASRを管理する仕組みを一つに決める
ASRルールは、Intune、グループポリシー、Microsoft Configuration Manager、MDM、PowerShellなどで設定できます。
同じ端末の同じルールを、IntuneではAudit、グループポリシーではBlockというように重複設定すると、管理者が意図した結果にならないことがあります。MDMとグループポリシーが競合した場合、既定ではグループポリシーが優先される構成もあります。([Microsoft Learn][4])
導入前に、次の情報を一覧化しておきます。
- ASRルール名とGUID
- 現在のモード
- 設定元のポリシー
- ポリシーの割り当てグループ
- Intune、GPO、Configuration Managerなどの管理元
- 除外設定の有無
AuditからBlockへ進める手順
テスト端末と対象グループを決める
最初に、小規模なテスト用デバイスグループを作成します。
テスト端末は情報システム部門の端末だけでなく、実際に業務ソフトやマクロを使用している端末から選ぶことが重要です。
対象には、次のような利用者を含めます。
- ExcelやAccessのマクロを日常的に使う職員
- 専用の業務ソフトを使う職員
- 帳票出力やデータ連携を行う職員
- PowerShellやバッチ処理を使う管理者
- ソフトウェアの更新や配布を担当する職員
テスト期間は、単純な日数だけで決めないようにします。日常処理に加えて、月末締め、請求処理、データ取込、更新プログラム適用など、頻度の低い重要処理を含む業務サイクルを一通り確認できる期間を確保します。
Microsoftも、最初は小規模で管理されたパイロットグループからテストする方法を推奨しています。([Microsoft Learn][1])
Intuneなどで対象ルールをAuditに設定する
Intuneを利用している場合、現在のMicrosoftの案内では、Endpoint SecurityのAttack surface reductionポリシーを使用します。
基本的な設定の流れは次のとおりです。
- Intune管理センターでEndpoint Securityを開く
- Attack surface reductionからポリシーを作成する
- プラットフォームにWindowsを指定する
4.プロファイルにAttack Surface Reduction Rulesを指定する - 検証対象のASRルールをAuditにする
- テスト用のデバイスグループだけに割り当てる
Intune以外でASRを管理している場合は、既存の管理方法をそのまま使用します。導入テストのためだけに別の管理方法を追加すると、設定競合の原因になります。
すでにBlockやWarnで設定されているポリシーがある場合は、テストグループに重複適用されていないか先に確認してください。Auditポリシーを追加しても、別のBlockポリシーが同時に適用されていれば、安全な監査にはなりません。([Microsoft Learn][4])
業務ソフトを「起動するだけ」で終わらせない
Auditを設定した後は、実際の業務操作を一通り実行します。
確認項目の例は次のとおりです。
| 対象 | 実行する操作の例 |
|---|---|
| Excel・Wordマクロ | ファイルを開く、マクロを実行する、CSVを読み込む、帳票を出力する、PDFを作成する、外部ソフトを起動する |
| 業務ソフト | ログイン、検索、登録、印刷、CSV出力、バックアップ、アップデート、プラグイン実行 |
| メール関連 | 添付ファイルを開く、保存する、圧縮ファイルを展開する |
| 管理処理 | PowerShell、バッチファイル、WMI、タスクスケジューラ、ソフトウェア配布 |
| 定期処理 | 月次処理、締め処理、一括取込、データ連携、ライセンス更新 |
ASRルールによる影響は、アプリの起動時ではなく、印刷、更新、ファイル出力、外部プログラム起動などの途中で発生することがあります。「起動できたから問題なし」と判断しないことが重要です。
Auditで記録されたイベントを確認する
利用できる確認方法は、Microsoft Defenderのライセンスによって異なります。
| 確認方法 | 主な利用条件 | 向いている用途 |
|---|---|---|
| ASRルールレポート | Defender for Endpoint Plan 2またはDefender for Business | 組織全体の傾向、ルール別・端末別の確認 |
| デバイスタイムライン | Defender for Endpoint Plan 2またはDefender for Business | 特定端末で発生した前後の操作確認 |
| Advanced Hunting | Defender for Endpoint Plan 2 | 複数端末の集計、プロセスやコマンドラインの調査 |
| Windowsイベントビューアー | ローカル端末で利用可能 | ライセンスに依存しない端末単位の確認 |
ASRルールレポートでは、検知されたファイル、ルール、呼び出し元アプリ、端末、ユーザー、発行元などを確認できます。表示できるレポートや詳細情報はライセンスによって異なるため、契約中のプランに合わせて確認方法を選びます。([Microsoft Learn][1])
Windowsイベントビューアーで監査イベントを確認する
ローカル端末では、次のログを確認します。
アプリケーションとサービス ログ > Microsoft > Windows > Windows Defender > Operational
ASRルールに関係する主なイベントIDは次のとおりです。
| イベントID | 内容 |
|---|---|
| 1121 | Blockモードでルールが動作した |
| 1122 | Auditモードでルールが検知した |
| 1129 | Warnモードのブロックが解除された |
| 5007 | Microsoft Defenderの設定が変更された |
Audit中の業務影響を調べる場合は、まずイベントID 1122を確認します。Blockへの切り替え後は、1121が問い合わせ調査の手掛かりになります。([Microsoft Learn][5])
端末数が多く、Microsoft Defender for Endpointの高度なレポートを利用できない場合は、Windows Event Forwardingなどでイベントを集約する方法も検討できます。([Microsoft Learn][1])
Advanced HuntingでASRイベントを集計する
Defender for Endpoint Plan 2を利用している場合は、Advanced HuntingのDeviceEventsテーブルからASRイベントを確認できます。
最初に全体傾向を確認する例です。
DeviceEvents
| where Timestamp > ago(30d)
| where ActionType startswith "Asr"
| summarize EventCount=count() by ActionTypeこのクエリでASR関連のActionTypeごとの件数を確認し、件数の多いルールから詳しく調査します。Microsoftの資料では、特定ルールへ絞り込み、ファイル名、フォルダーパス、コマンドライン、呼び出し元プロセスなどを表示する方法も案内されています。([Microsoft Learn][6])
なお、Advanced Hunting上のASRイベントは、同一のプロセスについて一定時間内の重複が抑制される場合があります。表示件数を、そのまま実行回数と考えないようにしてください。([Microsoft Learn][6])
監査イベントを「例外にするか」で分類する
Auditイベントが発生しただけでは、誤検知とは判断できません。
イベントは「Blockにした場合、この操作が影響を受ける可能性がある」という手掛かりです。業務担当者と確認し、操作の必要性を判断します。
記録しておきたい項目は次のとおりです。
- ASRルール名とActionType
- 発生日時
- 端末名と利用者
- 呼び出し元のアプリやプロセス
- 対象ファイルと保存先
- コマンドライン
- 実行していた業務操作
- 発生頻度
- 業務を継続できる代替手段の有無
- アプリの発行元、署名、バージョン
- 業務システム担当者の確認結果
判断は、次のように分けると整理しやすくなります。
| 確認結果 | 対応 |
|---|---|
| 不要または不審な操作 | Blockする |
| 正当な操作だが、マクロやソフトを修正できる | 実装を修正して再度Auditする |
| 正当で一時的に必要、かつWarn対応ルール | Warnで段階展開する |
| 正当で必須、代替や修正が困難 | 必要最小限のルール別除外を検討する |
| 用途が確認できない | 除外せず、Auditを継続して調査する |
業務ソフトのベンダーへ問い合わせる場合は、「ASRで止まる」とだけ伝えるのではなく、対象ルール名、プロセス名、コマンドライン、対象ファイル、発生する操作を伝えると調査しやすくなります。
除外はルール別・ファイル単位を優先する
正当な業務への影響が確認された場合でも、すぐにフォルダー全体を除外してはいけません。
ASRの除外には、主に次の考え方があります。
- すべてのASRルールに適用するグローバル除外
- 特定のASRルールだけに適用するルール別除外
- Microsoft Defender Antivirus側の除外
原則として、特定ルールに対する、具体的なファイルまたはパスの除外を優先します。
Microsoft Defender Antivirusのファイル・フォルダー除外は、すべてのASRルールで同じように扱われるわけではありません。ルール別除外は、IntuneのEndpoint Securityポリシー、Microsoft DefenderポータルのEndpoint Securityポリシー、グループポリシーなどで設定できます。([Microsoft Learn][2])
避けたい除外例は次のとおりです。
C:\全体C:\Program Files全体- ユーザープロファイル全体
- Downloadsフォルダー全体
- Tempフォルダー全体
- 部門共有フォルダーのルート
- すべてのマクロファイルを保存しているフォルダー全体
除外されたファイルやフォルダーは、悪意のある動作が含まれていてもASRルールでブロックされません。さらに、そのファイルについてASRのレポートやイベントが記録されなくなるため、広い除外は調査能力も低下させます。([Microsoft Learn][2])
除外を登録する際は、次の情報も記録しておきます。
- 除外が必要なASRルール
- 対象ファイルまたはパス
- 業務上の理由
- 所有部署とシステム担当者
- ソフトウェアのバージョン
- 承認者
- 見直し期限
- 代替策や改修予定
ソフトウェアの更新で実行ファイルやパスが変わる場合もあります。除外を恒久設定として放置せず、更新時や定期点検時に再評価します。
BlockまたはWarnへ段階的に移行する
Audit結果を確認したら、ルール単位でBlockまたはWarnへ移行します。
複数のASRルールを一度に切り替えると、問題が起きた際に原因を特定しにくくなります。影響が大きいルールは、少数ずつ切り替える方が安全です。
| 展開段階 | 対象 | 実施内容 |
|---|---|---|
| パイロット | テスト端末 | Audit結果を反映し、対象ルールをBlockまたはWarnへ変更 |
| 部門展開 | 特定部署や業務グループ | 問い合わせ件数とBlockイベントを確認 |
| 全体展開 | 一般端末 | 安定したルールを順次展開 |
| 継続運用 | 全対象 | 新しいソフト、マクロ、更新プログラムの影響を監視 |
Microsoftは標準保護ルールについて、通常は広範なテストを行わずBlockまたはWarnで有効化できるとしています。一方、それ以外のASRルールについては、Auditでのテスト後にBlockまたはWarnへ移行することを推奨しています。業務ソフトへの影響が不明な環境では、標準保護ルールであっても、小規模な対象から展開する運用にすると変更管理がしやすくなります。([Microsoft Learn][2])
問題発生時の差戻し方法を決めておく
Blockへ切り替える前に、問題が起きた場合の差戻し手順を決めます。
基本方針は、ASR全体を無効化するのではなく、問題のあるルールだけを同じ管理ポリシー上でAuditへ戻すことです。
差戻し手順の例は次のとおりです。
- 問い合わせ対象の端末、利用者、発生日時を確認する
- イベントID 1121やデバイスタイムラインを確認する
- 該当したASRルールを特定する
- 対象リングのポリシーで、そのルールだけをAuditへ戻す
- 端末へのポリシー反映を確認する
- 業務操作を再実行する
- マクロ修正、ソフト改修、ルール別除外のいずれで対応するか判断する
- 対応後に再びBlockまたはWarnへ戻す
緊急差戻し用として別のASRポリシーを重ねると、設定競合が起きる可能性があります。展開リングごとに管理元を明確にし、同じ端末へ同じルールを複数ポリシーで設定しない構成が安全です。([Microsoft Learn][2])
問い合わせ窓口には、少なくとも次の情報を伝えてもらいます。
- 発生日時
- 端末名
- 利用者名
- 業務ソフトやOfficeファイルの名称
- 実行した操作
- 表示された通知やエラー
- 再現するか
- 業務を継続できる代替手段があるか
ASR導入で失敗しやすいポイント
Auditを情報システム部門の端末だけで行う
情報システム部門の端末では、業務部門固有のマクロや専用ソフトが実行されません。実際の利用者をパイロットへ含めないと、本番展開後に初めて影響が判明します。
アプリが起動しただけで問題なしと判断する
影響は、帳票出力、CSV連携、バックアップ、更新処理などで発生することがあります。テストでは、実際の業務手順を最初から最後まで実行します。
Auditイベントをすべて誤検知と考える
Auditイベントは誤検知一覧ではありません。Block時に影響する可能性がある操作の記録です。正当な動作か、不審な動作か、不要な古い処理かを確認する必要があります。
フォルダー単位で広く除外する
一つの実行ファイルを許可するために、Program Filesや共有フォルダー全体を除外すると、同じ場所に置かれた別のファイルもASRの対象外になります。
Warnなら業務を止めないと考える
Warnも基本的にはブロック動作です。また、ルールや管理方法によってはWarnを利用できません。解除に管理者承認が必要な環境では、問い合わせ対応の仕組みも必要です。([Microsoft Learn][2])
Auditのまま運用を終える
Auditではイベントを記録できますが、該当する動作を止めません。監査期間の終了日と、BlockまたはWarnへ移行する判断日をあらかじめ決めておきます。
ASRルール展開前の最終チェック
- テスト用のデバイスグループを作成した
- 実際の業務ソフトやマクロ利用者を含めた
- Intune、GPOなどの管理元を一本化した
- 既存のBlock・Warnポリシーとの重複を確認した
- 業務操作を起動から終了までテストした
- ASRレポート、Advanced Hunting、イベントID 1122のいずれかを確認した
- Auditイベントをルール、ファイル、操作単位で整理した
- 除外はルール別かつ必要最小限にした
- Warn対応の有無をルールごとに確認した
- Block後の問い合わせ先と差戻し手順を決めた
- Auditから本番モードへ移行する期限を決めた
ASRルールによる業務ソフトやマクロへの影響が分からない場合、最初に行うべきことは広い除外の設定ではありません。代表端末をAuditにし、実際の業務操作からイベントを集めることです。
次に、イベントが正当な業務なのか、修正できる古い処理なのか、除外が必要な動作なのかを整理します。そのうえで、問題のないルールからBlockへ移行し、必要に応じて対応するルールだけWarnを使います。
この順序で進めれば、業務を止めるリスクを抑えながら、ASRルールをAuditのまま放置せず、実効性のある防御へ移行できます。
[1]: https://learn.microsoft.com/en-us/defender-endpoint/attack-surface-reduction-rules-deployment-test “Test your ASR rules deployment – Microsoft Defender for Endpoint | Microsoft Learn”
[2]: https://learn.microsoft.com/en-us/defender-endpoint/attack-surface-reduction-rules-overview “ASR rules overview – Microsoft Defender for Endpoint | Microsoft Learn”
[3]: https://learn.microsoft.com/en-us/defender-endpoint/attack-surface-reduction-rules-reference “ASR rules reference – Microsoft Defender for Endpoint | Microsoft Learn”
[4]: https://learn.microsoft.com/en-us/defender-endpoint/attack-surface-reduction-rules-configure “Configure ASR rules and exclusions – Microsoft Defender for Endpoint | Microsoft Learn”
[5]: https://learn.microsoft.com/en-us/defender-endpoint/attack-surface-reduction-windows-events “Attack surface reduction events in Windows Event Viewer – Microsoft Defender for Endpoint | Microsoft Learn”
[6]: https://learn.microsoft.com/en-us/defender-endpoint/attack-surface-reduction-rules-monitor “Monitor ASR rule activity – Microsoft Defender for Endpoint | Microsoft Learn”
コメント