FIM ファイル整合性監視の準拠解説：オープンソース HIDS ツールの適性と限界

PCI DSS v4.0.1 の技術要件において、ファイル整合性監視（File Integrity Monitoring、FIM）に対応するのは Requirement 11.5.2 です。その狙いは、サーバ、端末、システムの重要ディレクトリに生じた異常な変更を、企業が遅滞なく把握できる状態にすることにあります。本標準は、重要なシステムファイル、構成ファイル、コンテンツファイルを対象とする変更検知メカニズムの整備と、少なくとも週 1 回の比較実施を明文で求めています。業界では、単なるスケジュール比較にとどまらず継続的な監視を用いることが一般的な推奨とされており、これにより改ざん・削除・不正な追加といった異常をより早く把握できます。検知そのものに加えて、審査では完全な監査証跡が保管されているかどうかも同様に重視されます。悪意ある改ざん、バックドアの埋め込み、規程違反の操作を、事後に追跡できるようにするためです。

コンサルタントからの補足：Requirement 10.3.4 が規定しているのは監査ログそのものの整合性監視であり、11.5.2 が対象とするシステムファイルや構成ファイルとは範囲が異なります。ただし根底にある考え方は同じで、保管された記録が改ざんされた場合に即座に検知できること、事後になって「そのデータはもはや信頼できない」と判明する事態を避けることが要点です。

FIM の要件を満たす手段は、商用セキュリティ製品やソフトウェアライセンスの購入に限られません。予算に制約があり、導入・運用コストを抑える必要がある中小企業、公共調達の入札事業者、スタートアップにとって、OSSEC や WAZUH といったオープンソースの HIDS（Host-based Intrusion Detection System、ホスト型侵入検知システム）も、審査に持ち込める正当な選択肢であり、FIM 準拠に必要な基本機能を備えています。ただし導入後に実際どこまで要件を満たせるかは、自社の環境構成、ルール設定、その後の運用体制に応じて個別に見極める必要があります。

FIM 準拠の中核要件とは何か

審査準備を支援してきた経験から言えば、多くの企業は「表面的な監視」で止まりがちです。ツールを導入し既定のルールを有効にしただけで準拠したと考え、審査の段階になって初めてギャップに気づく、というものです。11.5.2 の趣旨に本当に合致する FIM の仕組みには、次の三つが同時に備わっている必要があります。

• 検知：重要なシステムファイル、構成ファイル、業務の中核ディレクトリを能動的に監視し、追加・変更・削除・権限変更を把握すること。
• アラート：異常な挙動が発生した時点でアラート記録を生成し、操作の主体・操作時刻・変更内容を明確に残すこと。
• ログ保管：すべてのファイル変更記録を完全に保存し、事後の追跡調査を可能にして、追跡可能性の要件を満たすこと。

オープンソースの HIDS は、設計段階から端末のセキュリティ監視とファイル整合性検知を範囲に含んでおり、上記の一部を実装できます。要件を完全に満たせるかどうかは、導入方法とルール設定の作り込み次第です。

PCI DSS Requirement 11.5.2 の要点

PCI DSS v4.0.1 標準文書によれば、Requirement 11.5.2 は、重要なシステムファイル、構成ファイル、コンテンツファイルに対する無許可の追加・変更・削除が発生した際に担当者へ通知できるよう、変更検知メカニズム（たとえばファイル整合性監視ツール）を導入し、重要ファイルの比較頻度を少なくとも週 1 回に設定することを求めています。監査ログの保護に関する要件はこれとは別に Requirement 10.3.4 に規定されており、ファイル整合性監視または変更検知メカニズムによって、既存のログデータがアラートを発生させずに改変されることのない状態を確保するよう求めています。

出典：PCI DSS v4.0.1 標準文書、Requirement 11.5.2 および 10.3.4。正式な条文については PCI Security Standards Council が公表する版を参照してください。本稿は当社コンサルティングチームによる整理であり、条文の逐語訳ではありません。

OSSEC と WAZUH：代表的なオープンソース FIM ツール

FIM を実装できるオープンソースの選択肢は複数ありますが、ここでは代表的な二つを取り上げます。OSSEC は 2004 年に立ち上げられたオープンソースのホスト型侵入検知システム（HIDS）で、ファイル整合性監視機能を備え、無償で入手でき、Linux や Windows など主要なプラットフォームに対応しています。WAZUH は 2015 年に OSSEC のソースコードからフォークして独立に開発・保守されているプロジェクトで、元の FIM 中核機能に加えて、可視化された管理画面、アラート機構、ログ分析、コンプライアンスレポート出力などを追加しています。

二つのツールの適用場面

• OSSEC：導入が軽量でリソース消費も小さく、旧式サーバや低スペック端末など、運用を絞り込んだ場面でよく用いられます。基礎的な FIM 要件は満たせるはずです。
• WAZUH：可視化画面、アラート機構、コンプライアンスレポート出力を備えており、定常的な監査、外部審査への対応、多数のサーバ管理が必要な場面で選ばれることが多くなります。

両者に共通する点：いずれもオープンソースであり、ライセンス費用は発生しません。FIM 準拠の方策に組み込むかどうか、また審査を通過できるかどうかは、実際の構成、ルール設計、その後の運用管理に左右され、最終的には PCI DSS の要件を満たすことが前提となります。自社の要件に照らして採否を判断するか、商用製品と併用してください。

オープンソース FIM ツールの設定の考え方（原則的な参考であり、導入手順書ではありません）

以下は OSSEC／WAZUH における FIM 設定の考え方を示したもので、導入時に留意すべき技術上の要点を理解するためのものです。実際の本番投入前には、ルール設計、監視範囲の画定、例外処理について、PCI DSS の実務経験を持つコンサルティングチームによる確認をおすすめします。ルール設定が不適切だとアラートノイズが過多になり、監視範囲が不十分だと要件上の重要パスが漏れるためです。

• FIM 中核モジュールの有効化：エージェント側の ossec.conf を編集して syscheck ファイル検知モジュールを有効化し（既定では無効のため手動で有効にする必要があります）、整合性検証機能を有効にします。監視対象ファイルごとに検証用のフィンガープリントが生成され、その変化を比較することでファイルが改ざんされたかを判定します。
• 要件上必須となる監視ディレクトリの設定：審査で重点が置かれる項目に合わせて中核の監視パスを設定し、重要なシステムファイルと業務の中核ファイルを網羅します。
  Linux：/etc システム構成ディレクトリ、起動ディレクトリ、サービス構成ディレクトリ、業務プログラムディレクトリ。
  Windows：システム中核構成ディレクトリ、レジストリ、業務配備ディレクトリ、重要な構成ファイル。
  設定時は realtime="yes" によるリアルタイム監視と check_all="yes" による全属性検知を有効にし、ファイル内容、権限、所有者、更新時刻の変化がもれなく記録される状態にします。
• 追跡機能とアラートの有効化：審査範囲がより完全な追跡能力を求める場合は、whodata モードの有効化を検討します。OS の監査機構を利用して、ファイル変更の操作者、プロセス、時刻を記録でき、PCI DSS などが求める監査追跡の要件を満たすうえで有効です。
• ログ保管とレポート出力：WAZUH は可視化バックエンドを標準搭載し、FIM の異常記録を自動的に集約して、アラート集計、変更記録の照会、コンプライアンスレポート出力に対応します。OSSEC の場合は、要件で定める保存期間を満たすために、別途ログ基盤（SIEM など）と連携させる必要があります。

FIM 準拠におけるオープンソースの位置づけと限界

OSSEC や WAZUH を導入して FIM 監視を実装することで、次の観点を一定程度まで支えることができます。

• PCI DSS のファイル変更検知およびセキュリティ管理に関する規定への対応。
• 情報セキュリティと変更追跡に関する ISO 27001 の管理策への適合。
• 悪意ある改ざん、バックドアの埋め込み、内部の規程違反、ウイルスによるファイル改変といったリスクの早期発見。

ただしオープンソースは「入れれば通る」万能薬ではありません。実務では、ルールを環境に合わせて調整しなかった、アラートを担当者の対応につなげる運用がなかった、監視範囲が重要ディレクトリを取りこぼしていた——といった理由で、導入後も審査で指摘事項とされた例を数多く見てきました。FIM はホストセキュリティ準拠の基礎項目であり、審査で指摘を受けやすい領域でもあります。商用製品に加えて OSSEC や WAZUH を審査の選択肢に含めること自体は十分に現実的ですが、本格導入の前に、実務経験のあるコンサルタントとともに、監視範囲・ルールの論理・保管期間が自社の準拠範囲と監査要件に合致しているかを確認することをおすすめします。

むすび：Secure Vectors の視点

FIM は一つの技術的統制に見えますが、審査の現場では、その企業全体のセキュリティ管理の成熟度を映す指標の一つになることが少なくありません。ルールをどれほど精緻に設定しても、それに見合うアラート対応のプロセスと担当者の配置がなければ、条文が求める「速やかな通知」の趣旨は満たせません。FIM ツールの選定を検討中の場合、あるいは現行の監視体制と PCI DSS v4.0.1 の要件との差分を明確にしたい場合は、Secure Vectors のコンサルティングチームにご相談ください。

用語解説

• FIM（File Integrity Monitoring、ファイル整合性監視）：ファイルのフィンガープリント（ハッシュ値）の変化を比較することで、重要なシステムファイルが無許可で追加・変更・削除されていないかを検知する仕組み。
• HIDS（Host-based Intrusion Detection System、ホスト型侵入検知システム）：個々のホストや端末に導入し、システムの挙動、ファイルの変化、異常な振る舞いを監視する検知システム。
• syscheck：OSSEC／WAZUH に内蔵された FIM 機能モジュール。ファイル整合性の比較と変更検知を担う。
• whodata：OS の監査機構と組み合わせ、ファイル変更の操作者・プロセス・時刻を記録することで追跡性を高める上位の監視モード。
• 変更検知メカニズム（Change-detection mechanism）：無許可のファイル変更を検知して警告できる技術的手段を広く指す PCI DSS の用語。FIM ツールはその実装形態の一つ。

よくあるご質問（FAQ）

Q1：中小企業はオープンソースの FIM ツールだけで PCI DSS 審査を通過できますか。
オープンソースのツール自体は FIM 準拠に必要な基本機能を備えており、原理的には審査の根拠の一つになり得ます。ただし実際に通過できるかは、ルール設定、監視範囲、保管記録の完全性によって決まるものであり、ツールのライセンス形態によって決まるわけではありません。正式な審査の前に、設定が要件に合致しているかをコンサルタントに確認してもらうことをおすすめします。

Q2：FIM の比較頻度は必ず週 1 回でなければなりませんか。
週 1 回は PCI DSS v4.0.1 Requirement 11.5.2 が定める最低頻度です。業界ではリアルタイム監視をより望ましい実務とする見方が一般的で、とくにインターネットに露出するシステムやカード会員データを扱う重要システムでは、異常の発生から発見までの時間差を縮められます。

Q3：OSSEC と WAZUH のどちらを選ぶべきですか。
両者は位置づけが実際に異なります。リソースが限られ、サーバ台数が少なく、技術チームが小規模な企業はまず OSSEC を検討してください。定常的な監査レポート、可視化された管理画面、多数のサーバ管理が必要な企業には WAZUH のほうが実務に近いでしょう。自社のサーバ規模、運用体制、監査レポート要件に照らして判断してください。

Q4：FIM はサーバだけを監視すればよいのですか。
サーバに限りません。カード会員データ環境（CDE）に含まれるシステムコンポーネントであれば、端末機器やネットワーク機器の構成ファイルも含め、重要なシステムファイルや構成ファイルに関わる限り FIM の監視範囲として検討すべきです。