ポリシーのコントロール (Living off the Landファイルアクセスの正当化)

Living Off the Land (LOTL) シナリオ向けのポリシー例

本例は、Living Off the Land (LOTL) のシナリオ向けに設計したファイルアクセスポリシーを示します。有効にすると、特定として識別した組み込みまたは悪用されやすいプロセスを対象に、操作が許可される前にユーザーに正当な理由の入力を求め、すべてのエンドポイントにわたる説明責任と監査のコントロールポイントになります。LOTL 正当化ポリシーをこのように整えたうえで、同じツールを信頼できるユーザーまたは自動プロセスがプロンプトなしで実行できるよう許可ポリシーを重ねたり、より高リスクのシナリオでは承認や拒否へエスカレーションしたりできます。


このポリシーの動作

対象内エンドポイント上のユーザーが、対象の LOTL プロセスを起動しようとするとき、以下のとおりです。

  1. 要求はファイルアクセスのポリシーエンジンで評価されます。

  2. ポリシーは特定のアプリケーション識別子を対象にしているため、それらのエンドポイント上では、そのプロセスの実行試行にだけ一致します。

  3. 操作が続行される前に、ユーザーは正当な理由を入力する必要があります。操作自体はブロックされませんが、監査ログに残る説明を入力するまで先へ進めないようになっています。

この動作の理由

このポリシーは意図的に「対象を絞った一致」として書かれ、全面的なブロックではなく説明責任の摩擦を加えます。

  • 適用: ポリシーは有効で、(ログだけでなく) コントロールを適用します。

  • 一致時の正当化コントロール: ポリシーに一致すると、操作が進む前にユーザーに業務上の正当な理由の入力が求められます。正当な理由は監査ログに記録されます。

  • すべてのユーザー: ワイルドカードのユーザーフィルターにより、対象マシン上のあらゆるユーザーアカウントに適用されます。既定では正当化要件から誰も除外されません。

  • 特定のアプリケーション: 単一の定義済みアプリケーション識別子は、特定の LOTL プロセスだけを対象にするため、同じエンドポイント上の無関係なアプリケーションには影響しません。

  • 確認が必要: 正当な理由に加えて、ユーザーは通知を明示的に確認する必要があります。記録だけでなく、コントロールの内容がユーザーに伝わることが保証されます。

  • 組み込みチェック: 標準のチェック (ユーザー、マシン、ファイル、日時・曜日、証明書) があります。日時・曜日・証明書の制約を適用していないため、対象エンドポイント上の対象プロセスに対してポリシーは常に有効です。

ユーザー側で起きること

  • 対象内エンドポイントで、対象の LOTL プロセスを起動しようとすると、ツールを使う理由を入力する必須テキストである正当化プロンプトが表示されます。

  • 続行する前に通知を確認する必要もあります。

  • 正当な理由の送信と通知の確認のあと、操作は続行できます。このポリシーは「プロンプトして記録」であり「ブロック」ではありません。摩擦は意図的ですが、正当な必要があるユーザーの作業は止めません。

  • 通知メッセージは、どのツールが制御されているか、なぜ正当な理由が必要かを明確に説明し、理由のない中断にならないようにしてください。


重要な注意点とよくある調整

  • 必要に応じてアプリケーション一覧を拡張する:

    • 同程度の正当化摩擦が妥当な別の LOTL バイナリやバリアント (別のスクリプトエンジン、インタープリター、リモート実行ユーティリティなど) をカバーするために App ID を追加する

    • 証明書の制約で未署名または未信頼のビルドにだけ適用し、正当に署名されたシステム構成要素にはプロンプトを出さないようにする

  • 低摩擦の例外でユーザースコープを狭める:

    • IT職員や自動サービスアカウントがプロンプトなしで自由にツールを実行する必要がある場合は、ユーザーフィルターを標準ユーザーに限定する

    • 信頼できるユーザーまたは特定のマシンコレクション向けに、別の優先度の高い許可ポリシーを作成する

  • パターンが見えたらコントロールをエスカレーション:

    • 監査ログに繰り返し不審または説明のつかない正当な理由が出る場合は APPROVAL にエスカレーションし、ツールを実行する前に人間の承認者を要するようにする

    • 環境に正当な用途がないと判断したツールは DENY にエスカレーションし、完全にブロックする

  • ツールに定義された正当な利用時間帯 (メンテナンスウィンドウや営業時間のみなど) がある場合は、時刻・曜日・日付の制限を加える

  • リスクレベルを意味のある値に: リスクレベルの値はレポートやダッシュボードに表示されます。高リスクの LOTL バイナリでは、正当化イベントがセキュリティレビューで目立つよう値を上げること (例: 75〜90) を検討してください


LOTL 正当化ファイルアクセスポリシーの作成手順

1

ポリシーの作成

Keeper管理コンソールのエンドポイント特権マネージャーページでポリシータブを開き、ポリシーの作成ボタンをクリックします。

ポリシー作成フォームがモーダルウィンドウで開きます。

2

ポリシー名

新しい LOTL 正当化ファイルアクセスポリシー用の、内容が分かる名前を入力します。ポリシー一覧で識別しやすいよう、対象プロセス名をポリシー名に含めること (例: _FileAccess_Justify_WScript) を推奨します。

3

ポリシータイプ

ポリシータイプの選択リストからファイルアクセスを選びます。

4

ステータス

ポリシーの作成フォームを完了して送信したときに、新しいLOTL 正当化ファイルアクセスポリシーに付けたいステータスを選びます。正しいアプリケーションが対象になっていることを確認するまで、まず監視で始めることを強く推奨し、その後適用に切り替えてください。

5

コントロール

コントロールの追加サブフォームから正当な理由が必要を選びます。対象プロセスが起動されるたびに、ユーザーに業務上の正当な理由の入力を求め、監査ログに記録します。

6

ユーザーグループ

ポリシー作成フォームでグループの追加リンクをクリックします。グループの追加サブフォームが開きます。

グループの追加サブフォームですべてのユーザーを選択にチェックを入れ、サブフォームの外側をクリックして閉じます。すべてのユーザーとグループが、LOTL 正当化ファイルアクセスポリシーに適用されたユーザーグループの下に表示されます。

正当化プロンプトから除外すべき特定のユーザーまたはサービスアカウント (例: IT管理者) がいる場合は、ここで除外するのではなく、別の優先度の高い許可ポリシーで対象を絞ってください。

7

マシンコレクション

ポリシー作成フォームで マシンコレクションの右にあるコレクションの追加リンクをクリックします。コレクションの追加サブフォームが開きます。LOTL 正当化ファイルアクセスポリシーに適用したいマシンコレクションを選択します。検索ボックスに入力して候補を絞り込みながら選んでも構いません。

LOTL 正当化ファイルアクセスポリシーに適用したいコレクションのチェックボックスにチェックを入れます。

選択したマシンコレクションが、LOTL 正当化ファイルアクセスポリシーに適用されたマシンコレクションの下に表示されます。

8

アプリケーション

ポリシー作成フォームでアプリケーションの追加リンクをクリックします。アプリケーションの追加サブフォームが開きます。

対象にしたい特定の LOTL プロセスを検索して選択します。すべてのアプリケーションを選択のチェックボックスは使わないでください。このポリシーは意図的に、正当化摩擦が妥当な特定の高リスクバイナリにだけスコープが絞られています。対象にしたい各アプリケーションのチェックボックスにチェックを入れます。

選択したアプリケーションが、LOTL 正当化ファイルアクセスポリシーに適用されたアプリケーションの下に表示されます。

9

日付と時刻

LOTL 正当化ファイルアクセスポリシーでは、日付と時刻の範囲常時にすることを推奨します。営業時間外を含め隙間なく正当化要件が適用され、LOTL の悪用が気づかれにくい時間帯もカバーされます。

10

LOTL 正当化ファイルアクセスポリシーの保存

これまでの手順どおりフォームに十分入力すると、保存ボタンが非アクティブからアクティブに変わります。保存をクリックします。ポリシーの作成モーダルが閉じ、LOTL 正当化ファイルアクセスポリシーが保存されます。


代表的な利用場面

このパターンは、既知の LOTL バイナリにだけ対象を絞った正当化コントロールをかけるものです。エンドポイント特権マネージャーでは、単に監査ログへ記録するだけより強く、いきなり全面ブロックや承認ワークフローほど重くない、中間の強さの制御として位置づけられます。主な利用場面とその背景を以下に整理します。

基本的な考え方: 「二面性のあるツールへの説明責任の摩擦」

Living Off the Land バイナリは正当なシステムツールです。スクリプトエンジン、コマンドラインインタープリター、管理ユーティリティなどはOSに同梱されており、攻撃者にも悪用されやすい一方で、セキュリティ製品からも信頼されがちです。課題は、これらのツールに正当な業務利用がしばしばあることです。正当化ポリシーは、この相反する要求のあいだを埋めます。正当な利用はブロックせず、匿名の利用はなくします。すべての実行は記録に残り、特定のユーザーに帰属し、入力された理由が残ります。インサイダー脅威と侵害されたアカウントの両方にとって、検出されず疑問も持たれない実行に依存するリスク計算を変えます。

主な利用場面

1. 二面性のある管理ツールの監査

たとえば wscript.exemshta.exerundll32.execertutil.exeregsvr32.exe などは標準の Windows 構成要素でありながら、脅威アクターの戦術のかなりの割合に現れます。これらのバイナリに正当化ポリシーを適用すると、各利用が特定のユーザーに帰属し、記録された業務上の理由付きで包括的な監査記録が得られ、それらに依存するITや開発のワークフローを乱しません。

2. エスカレーション前の行動ベースライン化

LOTL バイナリに拒否承認を課す前に、組織は実世界での利用量と性質を把握する必要があります。適用で展開した正当化ポリシーは、これを自然にデータ化します。正当な理由の提出そのものが、誰がどのくらいの頻度で、どのような目的で、どのマシンからツールを使うかを示します。この情報が、コントロールを厳しくするか緩めるか、維持するかの判断に直結します。

3. コンプライアンスおよび監査証跡

多くのコンプライアンス枠組み (NIST 800-171、CMMC、CIS Controls) では、高リスクのシステムツールへのアクセスが監視され帰属付けられることの証拠が求められます。正当化ポリシーは、対象バイナリの各実行についてタイムスタンプ付きでユーザーに帰属した監査記録を残し、完全な承認ワークフローなしに文書化と説明責任の要件を満たします。

4. インサイダー脅威の抑止

書面の正当な理由を求めること自体が抑止になります。強力なシステムツールを軽率または機会主義的に悪用しようとするユーザーは、行動が身元と必須の説明付きでログに残ることを知ると、そうしにくくなります。摩擦は手続き上だけでなく心理的でもあり、組織が注意を払っているというシグナルになります。

5. 脅威インテリジェンスに対する段階的対応

脅威インテリジェンスが、自社の業界や技術スタックを狙うキャンペーンで特定の LOTL バイナリが積極的に悪用されていると示したとき、正当化ポリシーを即座に展開すれば、低い運用リスクで迅速な第一対応になります。正当なアクティブ利用があるツールをいきなりブロックする運用リスクなしに、可視性と説明責任を同時に得られ、承認や拒否へのエスカレーションが妥当か評価できます。

6. ポリシー成熟の移行期のコントロール

エンドポイント特権マネージャーの姿勢を成熟させる過程では、正当化ポリシーが中間の段階として機能します。以前は無制御だったバイナリは、まず正当化付きの運用に移し、データとユーザー意識を得てから、すべての利用に人間の承認が必要なツールでは承認へ、正当な用途が残らないツールでは拒否へと進められます。この段階的な進め方は、ハードブロックへの移行が速すぎることによる組織リスクを下げます。


ファイルアクセスポリシーとする理由 (特権昇格ポリシーではない理由)

細かいが重要な違いです。ファイルアクセスポリシーは、ファイルの実行 (プロセスが起動した瞬間) をポリシー評価でインターセプトします。特権昇格ポリシーは、昇格した権限で何かを実行しようとしたときにだけインターセプトします。LOTL バイナリは、しばしば昇格なしの標準ユーザー権限で起動されるからこそ特に危険です。ここではファイルアクセスを使うことで、ユーザーがどの権限レベルで動いていてもあらゆる起動試行に正当化コントロールがかかり、対象プロセスを完全にカバーします。

ベースラインを土台としたレイヤー型のポリシー戦略

LOTL 正当化をベースラインとする構成が整ったら、その周りに制御された例外扱いとエスカレーションのモデルを重ねられます。

優先度の高い許可ポリシーに一致したユーザーは、そのまま通過します。承認ポリシーに一致したユーザーは、人間の承認者による確認のあと続行します。残りのユーザーはすべて、続行する前に正当な理由の入力が必要です。


運用上の重要な考慮事項

このポリシーは正当な理由が必要なコントロールと通知の必須確認を使うため、対象プロセスを起動するたびに影響を受けるユーザーはプロンプトで中断されます。まず監視で正しいアプリケーション識別子が対象か、実行頻度を測ってから適用に切り替えることを強く推奨します。特に正当な利用が多く、規模でかなりのプロンプト量になり得るバイナリではなおさらです。

最終更新