Cloud One Workload Securityの変更監視を利用して独自システムのソースコード、設定ファイルを変更監視してみた

2022.09.21

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、コンサル部@大阪オフィスのTodaです。

トレンドマイクロ社が提供しているCloud One Workload Securityでは変更監視をおこなう機能がございます。
前回、推奨設定検索と反映により変更監視もトレンドマイクロ社が推奨する監視を設定する事ができます。

ただし、推奨される変更監視は Apache などメジャーなソフトの監視は対応していますが独自に開発したシステムではルールを追加して監視に追加する必要がございます。
今回は、変更監視に独自ルールを追加して追加で監視出来るようにしてみます。

Cloud One Workload Securityとは?

Cloud One Workload SecurityはDeep Securityと表現すると知っている方も多いと思いますが、Trend Microのクラウド対応のセキュリティ製品群の1つです。

EC2などのサーバのセキュリティ対策は、Workload Securityを利用いたします。
サーバ上で動くアンチマルウェア/IDS/IPS/変更監視/セキュリティログ監視/Webレピュテーションなどのセキュリティ機能を有しており、多くの脅威からサーバを保護いたします。

■ Trend Micro Cloud One™ Workload Security
https://www.trendmicro.com/ja_jp/business/products/hybrid-cloud/cloud-one-workload-security.html

変更監視について

変更監視(整合性監視モジュール)は、レジストリ値、レジストリキー、サービス、プロセス、インストール済みソフトウェア、エージェント上のポートおよびファイルに対する予期しない変更を監視する仕組みになります。
安全な状態(ベースライン)と比較をおこない変更があった場合にログの記録と任意でアラート通知をおこないます。

■ 変更監視 - Cloud One
https://cloudone.trendmicro.com/docs/jp/workload-security/integrity-monitoring/

変更監視のルール設計について

変更監視はレジストリ値やファイルを指定する事で監視をする事ができます。
変更監視は範囲が大きくなると監視処理の負荷や、 ログなど変更が許容出来るファイルが入り込んでアラートが頻発して運用側の手間になる場合があるため最小限にて設定が推奨されます。

変更監視のルール設計について

監視は属性またはコンテンツハッシュアルゴリズムの変化によって判定されます。
属性は下記指定が可能になります、また、複数の属性があらかじめ提示されている属性もございます。
初期の設定では「STANDARD」が属性として指定されています。

■ 簡略記法による属性

  • STANDARD: 下記Created、LastModified、Permissions、Owner、Group、Size、Contents、Flags(Windowsのみ)), SymLinkPath(Unixのみ)が定義
  • CONTENTS: ポリシーエディタの[ 変更監視 ]→[Advanced]で設定されたコンテンツハッシュアルゴリズムに解決

■ よく利用する個別属性

  • Created: 作成日時のタイムスタンプ
  • LastModified: アップデート日時のタイムスタンプ
  • LastAccessed: 最終アクセス日時のタイムスタンプ
  • Permissions: 権限
  • Owner: 所有者
  • Group: グループ
  • Size: ファイルサイズ

その他属性は下記、ユーザガイドを参照ください。

■ FileSet 変更監視 - Cloud One
https://cloudone.trendmicro.com/docs/jp/workload-security/integrity-monitoring-rules-fileset/

変更監視ルール設計の注意点

・変更監視をする範囲は最小限にて設定
変更監視処理はファイル点数が多くなると負荷の増加、時間がかかります。
監視が必要な最小限の分のみ適用が推奨されます。

・推奨設定と被らないように注意
推奨検索にて変更監視している部分は、重複して監視しないように注意が必要です。

設定方法について

実際に独自システムの変更監視をおこなってみます。
今回はインスタンスの「/opt/test_app/」ディレクトリにシェルスクリプトを配置してそちらを変更監視します。
ポリシーの設定はインスタンスにおこないます。

インスタンスの変更監視設定へ

C1WSの画面にログインをおこない、画面上部の[コンピュータ]から移動します。
対象のインスタンスを選択してダブルクリックにて詳細を表示します。

インスタンスの変更監視設定へ1

左メニューから[変更監視]を選択します。

インスタンスの変更監視設定へ2

独自ルールの新規登録

変更監視ルールの[割り当て/割り当て解除]からルール選択に移動します。

独自ルールの新規登録1

ルール一覧上部の新規から[新しい変更監視ルール...]を選択します。

独自ルールの新規登録2

独自ルールの設定

一般設定にて名前と説明、重要度を指定します。
※重要度はソートや表示が変化するのみで処理への影響はございません。

独自ルールの設定1

コンテンツ設定では実際に監視対象にするファイル、ディレクトリを指定します。
テンプレート3点が選択出来て、今回は「ファイル」を指定します。

  • レジストリ値 : Windows関連のレジストリを監視
  • ファイル : 指定ディレクトリのファイルを監視
  • カスタム (XML) : 監視設定をまとめたXMLにて適用

ディレクトリは今回、サンプルで「/opt/test_app/」を指定しています。
またファイルは拡張子shの分のみ監視します。
ファイルの指定はワイルドカード文字が指定できて、「?:任意1文字」および「*:任意複数文字」を使用できます。
属性は監視対象とする項目をしている枠になっており上記で記載した属性になります。
今回は「STANDARD」を指定します。

独自ルールの設定2

オプション設定は監視異常時にアラートとして表示するか、リアルタイム監視を許可するかの設定になります。
今回は両方の設定を許可して画面下の[OK]をクリックします。

独自ルールの設定3

設定が完了しますと一覧に戻り先ほど作成したルールが表示されます。
表示されない場合は、表示設定を[すべて]または[割り当てなし]を選択して表示されるかをお試しください。

独自ルールの設定4

ルールの適用

作成者ルールの右横にあるチェックをつけて[OK]ボタンをクリックします。
上記にてルールの設定は完了になります。

ルールの適用

ベースラインの再構築

ルールが適用出来たら、正常なファイル状態のベースライン構築をおこないます。
画面内の[ベースラインの再構築]をクリックして再構築をおこないます。
処理は数分かかります。

ベースラインの再構築

再構築完了にて対象ファイルの変更監視が開始されます。

変更監視の動作確認

作成した変更監視が実際に動作するかを確認いたします。
監視対象のディレクトリ内にあるシェルスクリプトを手動変更します。
数分経過後にC1WSの[ダッシュボード]または[アラート]を確認すると警告アラートが表示される事が確認できました。

変更監視の動作確認

さいごに

今回はC1WSに用意されている変更監視に独自ルールを追加する方法をご案内いたしました。
独自システムをインスタンスで利用している場合、推奨設定検索ではルールが追加されませんので必要な場合は独自ルールによる変更監視をお試しください。
少しでもお客様の参考になればと考えております。