Snare WindowsエージェントとWinSyslogで脅威に備える（４）ファイルアクセスを監視する

はじめに

今回はファイルへの不正アクセス検出に威力を発揮するSnare Windowsエージェントのファイルアクティビティ監視（File Activity Monitoring）の機能を紹介します。これは前回のファイル整合性監視（File Integrity Monitoring）の機能とは違って、Windowsの機能を利用したファイル監視機能です。

このブログでは簡単のため、Snare WindowsエージェントおよびSnare Windows DesktopエージェントをまとめてSnare Windowsエージェント、もしくは単にSnareと呼んでいます。

FAM（ファイルアクティビティ監視）とは

FIM（ファイル整合性監視）とFAM（ファイルアクティビティ監視）の違いについては、前回のブログに比較表があります。今回のテーマであるFAMについてFIMに対する相違点に着目して整理すると以下のようになります。

FIMとFAMの違いのまとめ

  • FIMはSnare独自機能ですがFAMはWindowsに備え付けの機能を使っています
  • FIMはリアルタイム監視が苦手ですが、FAMはリアルタイムのファイルアクセス監視ができます
  • FIMはファイル内容が変わったことは分かりますが、FAMは書き換わったかどうかは分かりません
  • FIMは誰がいつ書き換えたのか分かりませんが、FAMはファイルの読み出しも含めて誰がどのプログラムでいつどんなアクセスをしたかチェックすることができます
  • FAMはFIMと比べてノイズとなるログが発生しやすく、アクセスごとにログが発生するのでログ量が膨大になりがちです
  • FIMは日本語（ワイドキャラクター）の使用に問題はありませんが、FAMはSnareの設定で監視するファイルのパス名やフィルターの指定に日本語（ワイドキャラクター）が使えません

上記特性を生かして、FIMとFAMを使い分けることが重要です。重要なファイルについては、FIMとFAMの両方で監視することも考えられます。しかし、当然のことながらFIMによるアクセスについてもFAMのログが発生してしまうので、ログ量が無駄に増えます。特に、アラートを上げる目的がある場合など注意が必要です。用途に応じてFIMとFAMを使い分けるのがよいでしょう。

FAMの活用方針案

これらを踏まえると、以下のような使い方が現実的と思われます。

  • リアルタイムで改変や削除が許されないシステムファイルを監視し、メールアラート上げる
  • ランサムウェアなどによる重要な機密ファイルの改変や削除をリアルタイムで監視する
  • USBへのファイルのコピー等のような重要な機密ファイルの想定外の持ち出しを監視する

ファイル持ち出し監視に関しては、アラートを上げるのではなく他のログと合わせてファイルの盗難や想定外の持ち出しの被害を確認するためのログとして使うほうが無難でしょう。

SnareのFAM機能の特長

Windows自体のファイルシステムの監査機能はWindows OSの機能だけで使いこなすのは、それほど簡単ではありません。しかし、Snareを使えば、比較的簡単に狙ったファイルの監査設定ができて、それをSnareのGUI上で一元管理できます。更に、Snareにはフィルタリング機能があり、無駄なログの送信を抑えることができます。また、Snareには転送先や用途に応じてログフォーマットを選択できるというメリットもあります。

FAM対象ファイルの一元管理

WindowsのOSだけでファイルシステム監査を行う場合、監視対象のフォルダーやファイルへの設定は個々のファイルやフォルダーのプロパティの奥深くを開いて設定する必要があり手間がかかります。更に、そのような構成のためどこを監視対象にしてどのような設定を行ったのか管理が大変です。しかし、Snareを使えばSnareのGUI上で一元管理でき、とても楽になります。

フィルタリング

FAMで使うWindowsのファイルシステム監査では、ログが過剰に発生しがちです。しかし、Snareにはフィルタリング機能があり、不要なログはSnareで除外して送信することができます。正規表現も使えるので少々複雑な条件でも問題なく設定できます。

多様なログフォーマット

各種ログサーバーやSIEMで受信可能なログフォーマットをSnareは完備しているため、FAMのログを事実上すべてのログサーバーやSIEMで受信できます。そればかりでなく、JSONやSnare V2フォーマットでは、ログのXML部分を転送することができるので、SIEM等でのプログラムでの解析が楽に確実にできます。

Snareを使ったFAMによるファイルアクセス監視には、上記のようなメリットがありますので、FIMでは現実的には不可能なリアルタイムのファイル監視や読み出し監視に活用してください。

SnareとWinSyslogによるFAM機能の活用方法

FAMの設定によって採取されるようになるイベントログ

これから説明するFAMイベントの収集手順を実行すると、以下の表にあるイベントIDのログが採取される可能性があります。これらは、Windowsのシステム監査ポリシーのサブカテゴリの「ファイル システム（File System）」と「ハンドル操作（Handle Manipulation）」の有効化によって出力されるイベントです。サブカテゴリは、基本の監査ポリシーにはなく、詳細（高度）な監査ポリシーで有効となります。

以下の表に記載している「ハンドル操作の有効化」の欄は、これらのイベントを出力するために詳細な監査のサブカテゴリの「ハンドル操作」の監査設定の有効化が必要か否かを記述しています。

Event IDイベントの概要ハンドル操作
の有効化
4656オブジェクトに対するハンドルが要求されました。必要※
4658オブジェクトに対するハンドルが閉じられました。必要
4660オブジェクトが削除されました。不要
4663オブジェクトへのアクセスが試行されました。不要
4664ハード リンクの作成が試みられました。不要
4670オブジェクトに対するアクセス許可が変更されました。不要
4685トランザクションの状態が変更されました。不要
4690オブジェクトに対するハンドルの複製が試みられました。必要

※イベントID 4656は、MicrosoftのAudit File Systemの説明には、サブカテゴリ「ファイル システム」を有効にするだけでログが出力されると取れる記述があります。しかし、筆者がWindows 2022で試験したところでは、「ハンドル操作」を有効にしないとログが出力されませんでした。

主に監視対象とするイベント

ここでは先ほどの活用方針案に対して太字にしたイベントID 4663でファイルアクセス状況を監視する例を紹介します。

これから説明する手順でSnareでFAMを動作させると、アクセス要求段階で4656のハンドル要求のイベントが発生しますが、実際のファイルへのアクセス時には 4663もしくは4660が発生します。4660はオブジェクトの削除時発生するイベントですが、対象のオブジェクト名が出力されません。一方、4663ではファイル削除に際しても削除されたオブジェクト名を含むイベントが発生します。したがって4663だけを解析すれば、実際にどのファイルがどのプログラムで誰によって何が行われたか分かるからです。

監視対象サーバーでのSnareによるFAMログ採取のための設定

設定の概要

Snare WindowsエージェントでのFAMの設定方法は、「Snare Windows (Desktop) エージェント ユーザーガイド」の「8.2 ファイルアクティビティ監視（FAM）ポリシー設定」及び「付録G – FAM / RIM イベントの取得」に説明があります。こちらも参考にしてください。

ここでは日本語のWindows環境で、SnareのAdvanced Auditingを使わない前提でやり方を説明します。

SnareでWindowsのFAMイベントを収集するには、次の３つの作業を行う必要があります。

  • Windowsのセキュリティポリシーで、「ファイル システムの監査」を有効にする
  • Snare WindowsエージェントのWeb GUIでファイル/フォルダー/レジストリの監査設定を行う設定を有効にする
  • SnareWindowsエージェントのWeb GUIのFAMポリシー設定で個別のファイル/フォルダーの監査設定を行う

Windowsセキュリティポリシーの設定

secpol.mscコマンドまたはドメイン コントローラのグループ ポリシーの管理経由で、ローカルセキュリティ ポリシーを開きます。セキュリティ オプションを開いて、「監査: 監査ポリシー サブカテゴリの設定（Windows Vista以降）を強制して、監査ポリシー カテゴリの設定を上書きする」を有効にします。

更に「監査ポリシーの詳細な構成」＞「オブジェクト アクセス」＞「ファイル システムの監査」を「次のイベントを構成する」をチェックし、更に「成功」と「失敗」をチェックして有効にします。

SnareのGeneral Configurationの設定

Snare Windowsエージェントのv5.8.1までの場合は Web GUI > [General Configuration] > [Allow Snare to automatically set auditing of file/folder and registry for FAM/RAM policies?]　にチェックを入れます。v5.9.0からは以下のようにWeb GUI＞[Advanced]＞[General Configuration]と一階層深く、[Advanced]の下に[General Configuration]があります。

通常は、同じ画面の少し上にあるAllow Snare to automatically set audit configuration?がデフォルトでチェックされています。この場合、Snare が監査構成を自動的に設定します。これを前提に話を進めます。

Snareでの監査対象ファイルに対するFAM監査ポリシーの設定

Snare Windowsエージェントのv5.8.1までの場合は Web GUI > [Audit Policy Configuration]の一連のAudit Policyの下にFile Activity Monitoring (FAM) Policiesの設定欄があります。v5.9.0からは以下のようにWeb GUI＞[Log Sources]＞[Audit Policies]をクリックすると同じ[Audit Policy Configuration]の画面が開け、同様に下のほうにFAMの欄があります。

[Add FAM Policy]をクリックすると以下のFAMポリシーの設定画面が開きます。

対象ファイル／フォルダーの設定

Audit Policy Type の選択

この欄にはFile（ファイル）とFolder（フォルダー）の選択肢がありますが、Fileを指定した場合は一つのFAMのエントリで一つのファイルを指定する形になります。一方、Folderを選んで下にあるFAM Scopeでfilesを含む選択肢を選べば、フォルダー内のすべてのファイルを一度に選択することも可能です。ただし、その場合のすべてのファイルにはサブフォルダー内のファイルも含まれるので、注意が必要です。

File or Folder へのパス名の入力

Audit Policy TypeにFileを指定した場合は、そのファイルのフルパス名を、Folderを指定した場合は、そのフォルダーのフルパス名を入力してください。ここには、日本語（ワイドキャラクター）を含むパス名は入力できません。日本語のパス名のあるファイルもしくはフォルダーを指定する場合は、Windowsでの監査対象ファイル／フォルダーの設定方法で対応できます。

FAM Scope の選択

このFAM Scopeは、Audit Policy TypeでFolderを選択した場合の、そのフォルダー自身とその配下すべてのサブフォルダーおよびすべてのファイルの中の対象範囲です。This folderは、File or Folder の欄にパス名を入力したフォルダー自身を指します。filesは、This folder配下のすべてのファイルを指します。subfoldersは、This folder配下のすべてのサブフォルダーを指します。

このFAM Scopeは、Windowsのファイルやフォルダーの「プロパティ」＞「詳細設定」＞「監査」の「適用先」と対応しています。

アクセス許可（Permission）パターンの設定

Permissionsの設定は、FAM Scopeと同じく「監査」の「アクセス」の設定に対応しています。

「基本のアクセス許可」の表示との対応では、All permissionsがフルコントロール、Traverse・・・が実行、Create・・・が書き込み、Read/List・・・が読み取りに対応しています。更に、その下の項目は「高度なアクセス許可」との対応で見ると以下の表の項番5~9のようになります。

項番Snare / Permissions の表示Windows / 高度なアクセス許可 の表示
1All permissionsフルコントロール
2Traverse folder. Execute file. Read attributesフォルダーのスキャン/ファイルの実行
3Create files / folders.  Write data / attributes. Read attributes / permissionsファイル作成/データの書き込み
4Read / List folder.  Read attributes / permissionsフォルダーの一覧/データの読み取り
5Delete file / folder削除
6Change file / folder permissionsアクセス許可の変更
7Take ownership of file / folder所有権の取得
8Delete file / folder. Read / Change permissions. Take ownership削除、アクセス許可の読取り、アクセス許可の変更、所有権の取得
9All permissions except take ownership / change permissions属性の書き込み、属性の読み取り、
サブフォルダーとファイルの削除、
フォルダーのスキャン/ファイルの実行、拡張属性の書き込み、拡張属性の読み取り、
フォルダーの作成/データの追加、
ファイルの作成/データの書き込み、
フォルダーの一覧/データの読み取り

ファイルの破壊を問題にする場合は、項番3の書き込みと、5の削除で大部分はチェックできます。また、読み出しも含めてチェックしたい場合は、更に4の読み取りのチェックが必要です。完全で無駄のないチェックを行うには、All permissionsをチェックして、不要なアクセス種別をフィルターするのが確実です。

フィルタリング

General Search Term

General Search Termは、イベントログのメッセージ部分に対するフィルター機能です。検索文字として日本語（ワイドキャラクター）は使えません。日本語と英数字（ASCIIコード）が混在するメッセージの場合は英数字でフィルタリングが可能です。詳細は「Snare Windows (Desktop) エージェント ユーザーガイド」のGeneral Search Termの説明をご覧ください。

User Search Term

User Search Termは、ユーザー名に対するフィルター機能です。検索に使える文字コードはGeneral Search Termと同じです。詳細は「Snare Windows (Desktop) エージェント ユーザーガイド」のUser Search Termの説明をご覧ください。

その他の設定

Event Type

Event Typeの設定は、監査のエントリの上部にある「種類」に対応しており、Successが「成功」、Failが「失敗」、Bothが「すべて」（成功と失敗）、の選択に当たります。Success Audit（成功の監査）とFailure Audit（失敗の監査）のどちらか、もしくは両方ともの監査ログを出力するか決める設定です。Snareの送信ログの中では、ReturnCodeのフィールドにどちらの監査ログであるか出力されます。ReturnCodeについては、このシリーズの第二回ブログの「2.6 Snareからイベントログのフィールド分割」を参照してください。

監査のエントリ画面の上部
Alert Level

Alert Levelについては、このシリーズの前回ブログの「4.2. Severity Level（重要度）の設定」を参照してください。イベントログをSysrlogフォーマットで送信する場合のデフォルトは、Emergencyとなっているので、そのほかの設定状況によっては不要なログもかなり発生する可能性があることからレベルが高過ぎます。NoticeやInfoに修正したほうがよいでしょう。

ログサーバーWinSyslogでのログ解析方法

イベントID 4663のフォーマット

監視対象のイベントID 4663のログは、第二回のブログで示したフィールド分割だけでは十分な解析ができないので、更にこのログの日本語のメッセージ部分をフィールド分割します。

イベントビューアーで見たイベントID 4663のログ

イベントビューアーでイベントID 4663を開いてみると上記のようになっています。SnareからSYSLOG(RFC3164)フォーマットでWinSyslogに転送した場合は、この中の赤枠の部分がSyslogのメッセージの後ろの方のStringsの部分に入って送られてきます。この点は、第二回ブログの「2. Snare Windowsエージェントからのイベントログのフォーマット」の記述を参考にしてください。

監視対象の項目

この中かからログの日付やイベントIDに加えて、主に以下の項目が分かれば、これらを条件にアラートを上げることができます。アクセス要求情報のアクセスの欄にアクセス種別が入ります。イベント ID 4663のアクセス欄に入るアクセス種別の名称は別表にしてありますので、参考にしてください。

アカウント名、オブジェクト名、プロセス名、アクセス

例えば、書換えを許さないようなドキュメントに関しては、アクセス種別のWriteData、AppendData、DELETE、DeleteChildを監視すればよいでしょう。これでファイルを暗号化して書き換えるランサムウェアについてもチェックできます。アクセス権を書き換える、WriteAttributes、WriteEA、WRITE_DAC、WRITE_OWNERもチェックしたほうがよいアクセスです。また、USBへのファイルのコピー等の疑わしいファイルの読み取りに関しては、ReadDataの監視が必要です。

イベントID 4663のフィールド分割（再構成）

第二回で再構成したイベントログでは、残ったmsg部分に先ほどの赤い枠の内容が改行コードやタブが削除された形で入っています。WinSyslogの再構成の対象はmsg部分ですから、第二回の再構成の結果に対して更に上記の日本語部分に対する再構成を実施すればよいことになります。WinSyslogのメッセージの再構成については、第二回の「6. フィールド分割（再構成）の実際」を参照してください。

実際にイベントID 4663の日本語のメッセージ部分について再構成ファイルを作成してみました。

<PPRules>
  <Rule Property="u-msg" Syntax="204">&amp;#032;</Rule>
  <Rule Property="Filer" Syntax="204">サブジェクト:</Rule>
  <Rule Property="Filer" Syntax="204">セキュリティ ID:</Rule>
  <Rule Property="Filer" Syntax="201">セキュリティ ID:</Rule>
  <Rule Property="u-SecurityID" Syntax="204">アカウント名:</Rule>
  <Rule Property="Fille" Syntax="201">アカウント名:</Rule>
  <Rule Property="u-AccountName" Syntax="204">アカウント ドメイン:</Rule>
  <Rule Property="Filler" Syntax="201">アカウント ドメイン:</Rule>
  <Rule Property="u-AccountDomain" Syntax="204">ログオン ID:</Rule>
  <Rule Property="Filler" Syntax="201">ログオン ID:</Rule>
  <Rule Property="u-LogonID" Syntax="204">オブジェクト:</Rule>
  <Rule Property="Filler" Syntax="204">オブジェクト サーバー:</Rule>
  <Rule Property="Filler" Syntax="201">オブジェクト サーバー:</Rule>
  <Rule Property="u-ObjectServer" Syntax="204">オブジェクトの種類:</Rule>
  <Rule Property="Filler" Syntax="201">オブジェクトの種類:</Rule>
  <Rule Property="u-ObjectType" Syntax="204">オブジェクト名:</Rule>
  <Rule Property="Filler" Syntax="201">オブジェクト名:</Rule>
  <Rule Property="u-ObjectName" Syntax="204">ハンドル ID:</Rule>
  <Rule Property="Filler" Syntax="201">ハンドル ID:</Rule>
  <Rule Property="u-HandleID" Syntax="204">リソース属性:</Rule>
  <Rule Property="Filler" Syntax="201">リソース属性:</Rule>
  <Rule Property="u-ResourceAttr" Syntax="204">プロセス情報:</Rule>
  <Rule Property="Filler" Syntax="204">プロセス ID:</Rule>
  <Rule Property="Filler" Syntax="201">プロセス ID:</Rule>
  <Rule Property="u-ProcessID" Syntax="204">プロセス 名:</Rule>
  <Rule Property="Filler" Syntax="201">プロセス 名:</Rule>
  <Rule Property="u-ProcessName" Syntax="204">アクセス要求情報:</Rule>
  <Rule Property="Filler" Syntax="204">アクセス:</Rule>
  <Rule Property="Filler" Syntax="201">アクセス:</Rule>
  <Rule Property="u-Access" Syntax="204">アクセス マスク:</Rule>
  <Rule Property="Filler" Syntax="201">アクセス マスク:</Rule>
  <Rule Property="u-AccessMask" Syntax="202">*Enter value for 値*</Rule>
</PPRules>

アラートを作成したい場合はこれで再構成後のログに対して、主な項目としてのu-ObjectName(オブジェクト名)、u-ProcessName(プロセス名）、u-Access(アクセス)などのプロパティを使って条件を作成できます。プロセス名で、explorerやシステムでスキャンするプログラムなどは除くとノイズを除去できます。ただし、偽装される可能性も考慮してフルパス名で除外するなど注意深くやる必要があります。具体的なアラートの設定などはこのシリーズの第二回の「7. 再構成後のプロパティを使ったフィルタ条件の活用」を参考にしてください。

イベントID 4663のExcel表示

イベント ID 4663の場合は、リソース属性のフィールド内にカンマ「,」が含まれる場合があります。そこで、ファイルにカンマ区切りで出力してExcelで分割されたログのフィールドを正しく見るためにはクォーテーションで囲む必要があります。そのやり方ではコマンドラインでの扱いが面倒になるので、Excelでも扱いやすく汎用性のあるタブ区切りで分割されたログをファイルに出力するには以下のようにします。

WinSyslogでファイル出力の際にタブ文字を使うには、システムプロパティの「$TAB」を使う必要があります。アクションのファイルログを設定し、ファイルフォーマットのタブでカスタムフォーマットを選び、入力欄に以下の文字列を入れると、抽出したフィールドがタブ区切りされてファイルに出力できます。（u-msgの部分はイベント IDで決まっている冗長情報なので以下のリストに含めていません。）

%u-LogName%%$TAB%%u-Date/Time%%$TAB%%u-EventID%%$TAB%%u-Source%%$TAB%%u-UserName%%$TAB%%u-ReturnCode%%$TAB%%u-System%%$TAB%%u-TaskCategory%%$TAB%%u-SecurityID%%$TAB%%u-AccountName%%$TAB%%u-AccountDomain%%$TAB%%u-LogonID%%$TAB%%u-ObjectServer%%$TAB%%u-ObjectType%%$TAB%%u-ObjectName%%$TAB%%u-HandleID%%$TAB%%u-ResourceAttr%%$TAB%%u-ProcessID%%$TAB%%u-ProcessName%%$TAB%%u-Access%%$TAB%%u-AccessMask%%$TAB%%u-SourceCount%%$CRLF%

Excelでファイルを開く際にテキストウィザードを使ってタブで分割すれば、以下のようにイベントID 4663のログをフィールド分割して見ることができます。一番上の行には、上記の出力フォーマットの文字列から%やu-など不要な部分を削除して、カンマ区切りにしてExcelに読み込ませています。

イベントID 4663をフィールド分割してExcelで表示

監視対象ファイルとログ量の調整

監視対象ファイルの候補

前回のブログでFIMの監視対象候補としたシステムファイルは、ログ量やノイズを考慮するとFAMの監視対象としては必ずしも適切ではありません。しかし、単独のファイルで書き換えられると影響が大きいwin.ini、system.ini、hostsなどは、リアルタイム監視する価値があり、FAMで監視する候補となります。

ただしFIMと併用するとFIMによるアクセスログも発生するので、その点の考慮が必要です。また頻繁に読み出されたり実行されるファイルは、それにらによるノイズをフィルターするか無視する必要があります。

また、System32配下の*.exeや*.dllはフォルダー単位で設定せざるを得ず、サブフォルダー内のファイルもチェック対象となり膨大なノイズが発生するので、FAMの対象とするのは困難です。

重要な機密ファイルを置くフォルダーを決めておき、その中のファイル群をフォルダーごと監視するという使い方が考えられます。FAMでは、書き込みや削除、場合によっては読み出しも含めて監視することができます。ただし、アラートを上げる場合は、条件をチューニングして誤報が少なくなるよう工夫する必要があります。

付随して発生するハンドル操作のログ

本ブログの「4. 監視対象サーバーでのSnareのFAMログ採取の設定」に従ってFAMの設定を行った場合、詳細な監査の「ハンドル操作」のサブカテゴリが、成功/失敗とも有効となります。このため、イベントIDの4656、4658、4690のログが発生します。逐一ファイルに誰が何を行ったのかを完全にトレースするにはこれらのイベントも必要ですが、通常は不要です。特に4690のハンドルの複製のイベントは、通常は不要な情報しかないイベントが大量に発生する可能性があります。

これは、SnareのGeneral Configuration画面にあるAllow Snare to automatically set audit configuration? をチェックしているとSnareが自動的にハンドル操作の監査を成功・失敗とも設定するためです。

ハンドル操作のログをSnareのフィルターで除外する方法

メーカーの推奨通りAllow Snare …をチェックした状態で、ハンドル操作のログを抑止するには、FAM設定エントリのGeneral Search Termに ( ID: .*){5} を指定して正規表現でExcludeすることでも実現できます。General Search Termには日本語は入力できませんが、これならば問題ありません。4656、4658、4690は、ハンドルIDなどのID情報が多く、4663には少ないので、その違いを利用しています。

FAMのGeneral Search Termでハンドル操作のログを除外する設定

更に確実な方法としてAllow Snare…のチェックを外せば、Windowsでハンドル操作のサブカテゴリを監査からはずす方法が使えますので、参考にしてください。

付録：Windowsのファイルシステム監査関連の情報

アクセス 許可設定とログ内のアクセス 名称の関係

Snareのアクセス許可(permission)設定とアクセス マスクとの関係を表にすると以下のようになります。

更にアクセス マスク の各ビットと、イベントログ内でファイル システムへのアクセス(種別)の表示と、WindowsのGUIの「高度なアクセス許可」の名称との対応関係は以下の通りです。FAMで監査するアクセス許可の設定やイベントログのフィルタリング、収集したログの検索の参考にしてください。

アクセス マスク ビットとアクセス種別の対応表

ビットWindowsイベントログ内の
「アクセス」（種別）の表示（日本語環境）		Windowsの
「高度なアクセス許可」名称
24ACCESS_SYS_SECー
20SYNCHRONIZEー
19WRITE_OWNER所有権の取得
18WRITE_DACアクセス許可の変更
17READ_CONTROLアクセス許可の読み取り
16DELETE削除
8WriteAttributes属性の書き込み
7ReadAttributes属性の読み取り
6DeleteChildサブフォルダーとファイルの削除
5実行/スキャンフォルダーのスキャン/ファイルの実行
4WriteEA拡張属性の書き込み
3ReadEA拡張属性の読み取り
2AppendData (または AddSubdirectory または CreatePipeInstance)フォルダーの作成/データの追加
1WriteData  (または AddFile)ファイルの作成/データの書き込み
0ReadData　(または ListDirectory)フォルダーの一覧/データの読み取り

Windowsでの監査対象ファイル／フォルダーの設定方法

監査対象のファイルやフォルダーのパス名に日本語が含まれる場合は、SnareのGUIのFAMポリシーの設定で正しくパス名が入力できません。その場合の対処として、WindowsのGUIを使って対象のファイルまたはフォルダーにセキュリティ監査設定を行う方法をご紹介します。

例えば次のようなフォルダーのツリーがあり、「重要」フォルダーの下のファイル全部を監視する場合を説明します。

エクスプローラーで「重要」のフォルダーを右クリックしてプロパティを選択して開き、セキュリティのタブをクリックします。

右下の詳細設定をクリックして開き、監査のタブを選択します。

追加をクリックして、[フォルダ名] の監査のエントリの画面を開きます。

プリンシパルの選択をクリックして、オブジェクトピッカーが開いたら、everyoneを入力してOKをクリックします。アカウントを聞かれたら、ユーザー名とパスワードを入力してセキュリティプリンシパルの入力を完了してください。

以下のように監査のエントリの「種類」と「適用先」と「基本のアクセス許可」が入力可能となります。

ここでの「種類」は、SnareのFAMポリシーの設定画面のEvent Typeに対応しており、「適用先」はFAM Scopeに対応しています。

FAM Scopeとファイル/フォルダーの監査エントリの「適用先」との対応

FAM Scope監査「適用先」の日本語表示OI:オブジェクト継承CI:コンテナ継承IO:継承のみ
This folder and filesこのフォルダーとファイル〇ーー
This folder and subfoldersこのフォルダーとサブフォルダー―〇ー
This folder, subfolders and filesこのフォルダー、サブフォルダーおよびファイル〇〇ー
This folder onlyこのフォルダーのみ―ーー
Files onlyファイルのみ〇ー〇
Subfolders onlyサブフォルダーのみ―〇〇
Subfolders and files onlyサブフォルダーとファイル〇〇〇
  • 「ファイル(files)」は、当該フォルダー配下のファイルすべてであり、サブフォルダー内のファイルもすべて含む
  • 「サブフォルダー(subfolders)」は、当該フォルダー配下のフォルダーすべてであり、サブフォルダー内の更に下位のサブフォルダー等をすべて含む
  • 「このフォルダー(This folder)」を含まない場合は継承のみで、つまり自分のフォルダーには監査が設定されない

基本のアクセス許可はSnareのFAM設定のPermissionsに対応していますが、一対一対応ではないので注意してください。高度なアクセス許可を表示するをクリックすると以下の画面となります。　

この高度なアクセス許可の各項目と、SnareでのPermissionsの設定との対応関係を「 アクセス許可（Permissions）パターンの設定」のところで表にしてありますので、参考にしてください。

「種類」「適用先」「アクセス許可」を選択したら、OKを3回クリックしてプロパティを抜ければ設定は終了です。

上記の監査のエントリ画面には、□このコンテナー内のオブジェクトまたはコンテナーのみにこれらの監査設定を適用する(T) という設定があります。これをチェックすれば、フォルダー内のファイルだけに監査設定を行い、サブフォルダー以下のファイルには設定を継承しないことができます。これをチェックしない場合は、適用先に「ファイル」を入れた場合は、テスト１.txt、テスト２.txtだけでなく、１１、１２、２１、２２も監査対象となります。しかし、ここにチェックを入れた場合は、１、２だけに監査が設定されます。

SnareのGUIのメニューで作れないアクセス許可のパターンの監査条件を入れたり、上記のような機能を使う場合にも、このGUIなどWindowsで直接フォルダーやファイルに監査設定してください。

Windowsでハンドル操作のサブカテゴリを監査からはずす方法

SnareのGeneral Configuration画面で、Allow Snare to automatically set audit configuration?をチェックした状態でRestart Serviceをクリックして再起動でSnareに自動で監査設定させます。Allow Snare …のチェックを外して、Apply Configuration & Restart ServiceをクリックしてSnareをもう一度再起動させます。管理者権限のあるコマンドプロンプトで、auditpolコマンド を使って「ハンドル操作」だけ　成功も失敗もdisableにすれば「ハンドル操作」は「監査なし」の状態となります。

(ローカルセキュリティポリシーのWeb GUIでも同様のことは可能ですが、Snareで設定した値がWindowsのGUIでは読み取れないので、いずれにしてもauditpolコマンドを使う必要がります。)

auditpolコマンドで「ハンドル操作」を「監査なし」に変更する具体的な方法は、以下の通りです。

リファレンス

動作確認版数

本ブログ執筆にあたっては以下のバージョンで動作確認しました。

  • Windows Server 2022
  • Windows 10 Pro
  • Snare Windows Agent v5.8.1およびv5.9.0
  • Snare Windows Desktop Agent v5.8.1およびv5.9.0

SnareとWinSyslogのドキュメント

ブログ バックナンバー

Windowsのファイル システム監査の参考サイト

本ブログ執筆にあたっては主に以下のサイトを参考にしました

おわりに

最後までお読みいただき、ありがとうございました。このFAMの機能を活用する場合には、ログ量が膨大になりがちなので、対象や条件を絞ってノイズの少なく有効な設定を行うことが重要です。少ない労力でチェックしたいのであれば、FIMを使うことをお薦めします。

次回は、Snare Windowsエージェントのもう一つの特長であるWindowsサーバーのファイルに書き込まれるログを吸い上げてログサーバーやSIEMに転送する方法について具体的に説明します。

Snare紹介ページ
WinSyslog紹介ページ
お問い合わせ

30日無償で利用いただける評価版を以下のダウンロードリンクに用意しております。簡単に検証が開始できますので、ぜひお気軽にお試しください。

評価版ダウンロード

こんな記事も読まれています

最新記事

おすすめ記事

  1. 脆弱性対策は喫緊の課題　医療機関への攻撃事例から学ぶ、対策を急ぐために必要なこととは

  2. 【Checkmkプラグイン活用】第1回 Dockerコンテナ監視

  3. VPNでのリモート接続 不正にアクセスされていないか記録・調査していますか？

製品カテゴリー

NetFlow sFlow SNMP SSB syslog Syslogサーバー シスログサーバー セキュリティブログ トラフィック監視 ネットワーク監視 ログサーバー ログ保存 ログ管理 ログ管理ブログ 機器・サーバー監視のへや

JTC IT用語集
TOP