ファイル整合性監視（FIM）のベストプラクティス Top9

本文の内容は、2021年9月7日にAlejandro Villanuevaが投稿したブログ(https://sysdig.com/blog/file-integrity-monitoring/）を元に日本語に翻訳・再構成した内容となっております。

ファイル整合性監視のベストプラクティスを素早く適用することで、クラウド環境の重要なファイルシステムの改ざんを検出する方法をご紹介します。

攻撃者は、runcバイナリ（CVE-2019-5736）のような特定のファイルを改変することで、コンテナをエスケープしてシステムにアクセスすることができます。これらのファイルを監視することで、それらの不正な変更を検出し、それらの危険な試みに即座に対応することができます。

ファイル整合性監視（FIM）は、すべての機密ファイルの可視性を得る継続的なプロセスであり、継続的な攻撃を示す重要なシステムファイルやディレクトリの変更や改ざんを検出します。これらのファイルが改ざんされているかどうかを知ることは、インフラの安全性を維持する上で重要であり、攻撃の早期発見と事後の調査に役立ちます。

FIMは、PCI/DSS、NIST SP 800-53、ISO 27001、GDPR、HIPAAなどの多くのコンプライアンス基準や、CIS Distribution Independent Linux Benchmarkのようなセキュリティベストプラクティスフレームワークにおいて、中核的な要件となっています。

理想的なシナリオでは、不正な行為者によって機密ファイルに変更が加えられた場合、それが検知され、直ちに報告されるべきです。

インフラで使用しているツールについて、これらのベストプラクティスに従うことで、この種の攻撃を検知することができます。
ファイル整合性監視のベストプラクティスを図解したもの。コンテナ内のファイルに警告が表示されています。

この記事では、ホストとコンテナのセキュリティに焦点を当てて、FIMのベストプラクティスを厳選して紹介しています。

1. 資産インベントリーの作成
   1. 監視すべきファイルとディレクトリの範囲
   2. 適切なパーミッションの定義
   3. ベースラインの定義
2. ドリフトの検出
   1. イメージスキャンポリシーによるシフトレフト
   2. ランタイムポリシーによるリアルタイム脅威検出
3. 通知、調査、および対応
   1. 自動化された警告と応答のメカニズムの導入
   2. さらなる調査のためのフォレンジックデータの収集
4. コンプライアンスとベンチマーク
   1. コンプライアンス要件の遵守
   2. 自動化されたベンチマークの実施

このファイル整合性監視のベストプラクティスは、トピックごとに分類されていますが、FIMはセキュリティプロセス全体の中の一部分に過ぎないことを忘れないでください。

#1 資産インベントリーの作成

資産のインベントリーを維持することは、システムを保護するための最初のステップです。見えないものを守ることはできません。したがって、自分にとって重要なファイルとディレクトリのリストを作成することは、インフラに実装すべき最初のベストプラクティスです。

ここで注意したいことがあります。範囲が広すぎるとアラートの数が多くなり、誤検知やアラート疲れが発生して、FIM全体が信用できなくなり、価値がなくなります。

#1.1 監視すべきファイルとディレクトリの範囲

監視が必要なファイルとディレクトリの包括的なリストを作成し、維持します。これらの資産には、システムファイル、設定ファイル、および機密情報を含むファイルが含まれます。これらのファイルの多くは、実際のビジネスユースケースによって異なりますが、確実に監視したい共通の資産があります：

AWSを利用している場合は、S3バケットに保存されているログファイルなど、クラウドインフラに存在する資産を考慮する必要があります。

#1.2 適切なパーミッションの設定

アセットリストに含まれるファイルやディレクトリに、適切な書き込み権限を設定します。こうすることで、権限のないユーザーがこれらのファイルを変更した場合に、それを検知することができます。

特にコンテナでは、ホストから公開されているボリュームに書き込み権限があると、ホスト内の別のディレクトリやファイルへのシンボリックリンクを作成することができ、コンテナをエスケープするための第一歩となるためクリティカルです。

この時点で、通常のファイル書き込みとファイル破壊を区別することが重要です。というのも、インベントリ内の多くのファイルは日常的に追記される必要がありますが、切り捨てられたり削除されたりすることは想定されていないからです。このようなファイルの例としては、システム、シェル、またはアプリケーションのログファイルがあります。

各ファイルやディレクトリには、変更ポリシーを関連付ける必要があります。例えば、/bin または /sbin の下のファイルは変更してはならず、これらのディレクトリの下に新しいファイルを作成してはならず、mysql.log はサイズが大きくなることはあっても小さくなることはありません。

#1.3 ベースラインの定義

資産のチェックサムを計算し、安全な場所に保管して継続的にチェックしましょう。チェックサムはファイルの実際の内容を示すフィンガープリントであるため、フィンガープリントの保存値から不正に逸脱した場合は、ファイルが改ざんされたことを意味します。

#2 ドリフトの検出

アセットインベントリの情報（ファイルやディレクトリのリスト、それらのパーミッションやチェックサム情報）を使って、システムに異常がないか監視します。CI/CDパイプラインの早い段階で、またランタイムポリシーを使ってランタイムで準リアルタイムにドリフトを検出することができます。

#2.1 イメージスキャンポリシーでシフトレフト

アセットインベントリに関連するデータを保存し、それをイメージスキャンポリシーに組み込むことができます。これにより、CI/CDパイプラインでビルドを拒否することで、セキュリティをシフトレフトすることができます。

イメージ・スキャン・ポリシーを調整して、以下をチェックします：

• 存在しないはずのファイルやディレクトリが存在し、逆に存在するはずのファイルやディレクトリが存在しないことを確認する。
• 存在しないはずのファイルのパーミッション（書き込み、実行、SUID、GUIDなどのパーミッション）やスティッキービットの存在。
• 特定のファイルのチェックサムが、ベースラインと比較して不一致がある場合。

イメージスキャンに興味をお持ちの方は、dockerfileのベストプラクティスをお見逃しなく。

インベントリーがしっかりと定義されていれば、これらのポリシーを簡単に作成することができ、パイプラインでファイル整合性監視を行うことで、FIM関連のインシデントを未然に防ぐことができます。

Sysdig Secureによるファイル整合性監視のベストプラクティス。ファイルの存在、パーミッション、チェックサムをチェックするイメージスキャンポリシー

#2.2 ランタイムポリシーによるリアルタイム脅威検知

ランタイムドリフト検出ポリシーを導入し、ファイルシステムへの不正な変更を警告します。ランタイムポリシーをカスタマイズして、次のようなファイル整合性監視の一般的なユースケースを探します。

• ファイルやディレクトリの作成、名前の変更、または削除
• ファイルやディレクトリの属性の変更（パーミッション、所有権、継承など）
• コンテナ内のファイルの変更
• 機密性の高いパス（/bin, /etc, /root など）以下のファイルの変更
• シェルの履歴の削除

#3 通知、調査、そして対応

イメージスキャンポリシーでファイル整合性監視をシフトレフトさせ、ランタイムポリシーがリアルタイムに検知することで、資産インベントリーのドリフトを検知できるようになりました。適切に通知され、インシデントに適切に対応するために必要なすべてのデータが提供されなければ、このループは完成しません。

#3.1 自動化された警告と応答の仕組みを導入する

ランタイムポリシーでは、以下のような方法で修復対応を自動化します：

• 攻撃を止めるために、コンテナを一時停止して隔離、またはKillする。
• Slack、JIRA、メール、PagerDuty、SNSなどで通知を送信する。

#3.2 フォレンジックデータを収集して調査を進める

攻撃者は通常、従来のセキュリティツールやフォレンジックシステムを回避できることが証明されている戦術や技術を利用します。この問題を解決するには、コンテナやKubernetesのメタデータで適切に強化された低レベルのシステムコールデータを収集することで、信頼できる究極のフォレンジックデータを提供することができます。これをランタイムポリシーで実装することができます。

そして、オープンソースツールのSysdig Inspectを使って、疑わしいファイルアクティビティの直前と直後に起こったことをすべて分析することができます。

Sysdig Secureのアクティビティ監査では、疑わしいファイル・アクセスがハイライトされます。

#4 コンプライアンスとベンチマーク

前述したように、ファイルの整合性監視は、PCI / DSS 3.2.1のような重要なコンプライアンス基準を満たすために必要であり、以下のことが義務付けられています：

許可されていないユーザまたはプロセスによるこのようなログファイルの変更を検出することで、このPCIコントロール10.5.5への準拠を保証することができます。警告と応答のメカニズムをランタイムポリシーに実装することで、PCI コントロール 11.5.1 に準拠します。この 2 つは、PCI / DSS 3.2.1 でファイル整合性監視に関する唯一の管理項目であるため、前述のベスト プラクティスに従うことで、この基準の FIM 要件すべてに準拠することができます。

#4.1 コンプライアンス要件の遵守

前述したように、一部のコンプライアンス標準では、ファイル整合性監視戦略の実施が求められています。実装しようとしている規格を十分に検討し、どのファイルを監視する必要があるのかをしっかりと把握しておくこと。これらのログファイルに手を加えようとする行為は、おそらくホストに対する Indicator Removal 攻撃の手口です。

PCI / DSS がログファイルの整合性を監視することを望んでいることはすでに述べました。別の例として、NIST 800-53 のコントロール SI-07 では、組織で定義されたさまざまなオブジェクトに対して「不正な変更を検出するための整合性検証ツール」を使用するよう明示的に指示しており、コントロール AC-02 では、「ポリシーに従った情報システム・アカウントの作成、有効化、変更、無効化、削除」を監視するよう求めています。ISO 27001、GDPR、HIPAAなどの他の規格では、FIMの要件が異なる場合があります。

導入しているコンプライアンス標準の情報を抽出し、この必須データを備えた上で、#1で述べた資産インベントリーを準備するのはあなたの責任です。

#4.2 自動化されたベンチマークの実行

必要な情報源は、コンプライアンス標準だけではありません。自分の業界に合ったベンチマークのフレームワークを選び、それに従うようにすると、メリットは2倍になります。例えば、CIS Distribution Independent Linux Benchmarkには次のような記述があります。

このベンチマーク（または実施している特定のベンチマーク）のコントロールから重要な情報を抽出することができますので、フレームワークに目を通し、インベントリーを補完するために使用してください。

また、自動化されたベンチマークを導入すれば、インフラを定期的にスキャンして標準化されたレポートを作成し、インベントリーのベースラインからの逸脱に関する具体的で詳細な情報を得ることができます。

したがって、ある意味で、これらの最後の2つのベストプラクティスは、ファイル整合性監視戦略を成功させるときに注意する必要がある最初と最後のステップです。

まとめ

ファイル整合性監視は、攻撃者によるコンテナの侵害やシステムへのアクセスを検知するための鍵となります。

以下のことを忘れないでください：

1. センシティブなファイルのインベントリを作成する。
2. ファイルの変更、作成、削除を検知するように設定する。
3. 予期せぬ動作を効率的に通知し、フォレンジック調査を可能にする。
4. コンプライアンス標準を満たす。

これらのベストプラクティスに従うことで、攻撃者はお客様のインフラを侵害することが難しくなり、お客様は安心して夜を過ごすことができます。

Sysdig Secureで攻撃を検知する。マルウェアファイルのディレクトリへのコピー

ファイル整合性監視の動作を例で見てみましょう。

ここでは、ハッカーがコンテナ内の機密ファイルにマルウェアをコピーする攻撃を想定しています。そして、堅牢なFIMソリューションが、この攻撃を取り巻くすべてのアクティビティを検出・分析し、効果的な対応を可能にする様子を見ていきます。

ファイル整合性モニタリングの攻撃シナリオ：攻撃者がコンテナ内にマルウェアをコピーする。アラートを受け取り、フォレンジックデータを集めて何が起こったかを調査する

ハッカーがコンテナ（VMやベアメタルホストの場合もある）にアクセスし、/usr/binディレクトリにマルウェアをコピーし始めたとします。

攻撃者がコンテナにマルウェアをコピーしている端末。コンテナ内のファイルパスを変更したり、変更しようとしたりする行為は、侵害の指標となります。

実行時にホスト/コンテナを監視していれば、このような不審な活動に対してアラートが出されたはずです。

sysdig secureの不審なファイル変更アラート：Suspicious file change ruleがすぐに発動され、cp malware /user/bin/dpkgコマンドが実行されました。

さらに一歩進んで、このファイル変更にまつわる活動を掘り下げてみましょう。この攻撃は、JohnDoeというユーザーがポッドにkube-execして、機密性の高いJavaアプリケーションのネームスペースの一部であるディレクトリにマルウェアをコピーしたものです。

どのファイルが変更されたかを示す、Sysdig Secure監査ログの不審なファイル変更アラート：kube-execのセッション、接続、特定のファイル属性（ファイル名、ディレクトリ、コマンド、パーミッション）で監査証跡をフィルタリングします。

特にコンテナは刹那的なものなので、Kubernetes内部で何が起こっているのかを常に詳細に把握することは困難です。しかし、この監査証跡は、ファイルがどのように改ざんされたか、誰がその変更を行ったかを、クラウドやKubernetesの環境下で、またコンテナがなくなった後でも正確に示します。

Sysdig Secureは、ホストやコンテナへのFIMの導入を支援することで、お客様のセキュリティリスク管理をサポートします。

Kubernetes セキュリティの詳細については、製品ページをご覧いただくか、Sysdig Secureの30日間無料トライアルにお申し込みください！