Trend Vision One Endpoint Security Server & Workload Protectionでセキュリティイベントを２箇所に転送する方法

こんにちは！クラウド事業本部の吉田です。

Vision One使っていますか？

今回は、Trend Vision One Endpoint Security Server & Workload Protection(以降、V1ES)で、セキュリティイベントを２箇所に転送する方法をまとめてみました。

セキュリティイベントを２箇所に転送したいケース

本題に入る前に、セキュリティイベントを２箇所に転送したいケースとはどのようなものなのでしょうか？

様々なケースがあるかと思いますが、一つはセキュリティベンダーにセキュリティイベントを転送する一方で、会社のログ保管要件によって自社環境にもログを保管したいというケースです。

V1ESのセキュリティログを元にした24/365有人監視サービスを受ける場合は、大抵の場合セキュリティベンダー管理のログ保管サーバーにセキュリティイベントを転送する形になります。
その際、セキュリティベンダー管理のログ保管サーバーに保存するログの保存期間は、上限(３ヶ月など)が設けられていることが多いです。

ここで問題になるのは、V1ES上の保管期間もセキュリティベンダー管理のログ保管サーバー上の保管期間も、会社のログ保管期間要件に満たしていない場合です。
特別措置でセキュリティベンダーにログ保管期間延長を依頼することも手段の１つですが、不可能だった場合ログの長期保管のため自社環境側にもログを保管する必要があります。

そこで、セキュリティベンダー側にも自社環境側にもV1ESのセキュリティイベントを転送する必要が出てきます。

課題

セキュリティイベントの転送には、Syslogが多く利用されます。
ここで問題になるのは、Syslogの転送先は１つにしか指定できない 仕様です。

Syslogの設定は、Vision Oneのコンソール上の作業として「Syslog設定の作成」、「Syslog設定をポリシーにアタッチ」という２段階のプロセスがあります。
Syslog設定では、転送先のサーバーのIPなどを設定するのですが、ここで複数のサーバを設定することができません。
また、ポリシーも複数のSyslog設定をアタッチすることはできません。

このような仕様によって、Syslog単体では複数箇所にセキュリティイベントを転送することができません。

結論

いきなり結論です。
以下のように転送方法を使い分けることで、２箇所にセキュリティイベントを転送することが可能です。

• １箇所目の転送方法
  • Syslog
• 2箇所目の転送方法
  • AWSリソース活用
    • 具体的なアーキテクチャは、「Amazon SNS + Amazon Data Firehose + S3」

対応策について

１箇所目の転送方法：Syslog転送

１箇所目の転送方法は、従来通りのSyslogによる転送です。
セキュリティベンダーにセキュリティイベントを転送する際は、大抵はSyslogによる転送になるかと思われます。

具体的なSyslogの設定方法は、過去の私の記事が参考になるかと思います。

VPC内(プライベートネットワーク内)で、C1WSのセキュリティイベントをDSA経由でSyslogサーバに転送してみた | DevelopersIO

こちらの記事は、Trend Cloud One Workload Security、かつDSA経由でプライベートサブネット上のSyslogサーバに転送するという内容となっておりますが、基本的なSyslogの設定方法は同じとなります。

Syslog設定の内容は、以下のように読み替えてください。

• サーバー名
  • 転送先のSyslogサーバのホスト名・もしくはIP
• Agentによるログ設定方法
  • Workload Security Manager経由

公式ドキュメント：Workload Security イベントをSyslogまたはSIEMサーバに転送する | Trend Micro

2箇所目の転送方法：AWSリソース活用

２箇所目の転送方法は、AWSリソースを活用する方法です。
セキュリティイベントの転送方法の一つとして、Amazon SNSが利用できます。
Amazon SNSが受け口となり、Amazon Data Firehoseを経由してS3にセキュリティイベントログが保管されるといった流れとなります。
自社環境に上記のAWSリソース群を作成する形となります。

具体的な設定方法は、私の過去の記事を参考にしてください。

V1ESのログを、SNS + Amazon Data Firehose経由でS3に送信してみた | DevelopersIO

余談

余談として、当初検討していた構成もまとめます。

当初検討していた構成は下記の通りとなります。

• １箇所目の転送方法
  • Syslog
    • セキュリティベンダーに転送する形ではなく、DSA経由で自社環境上のSyslogサーバに転送
• 2箇所目の転送方法
  • SIEM
    • セキュリティベンダー側への転送方法

先ほどの構成と異なる点は、自社環境側への転送はSyslogを利用して、セキュリティベンダー側の転送はSIEMを利用する点です。
ここでいうSIEMを利用した転送とは、「管理」→「システム設定」→「イベントの転送」で設定できるSIEM設定を指します。
ただし、コンソール上の備考にある通り、こちらはSIEMでは、[システムイベント] タブにあるDSMイベントを転送する形となります。

Syslogメッセージは、[システムイベント] タブで転送対象として設定したイベントについてのみ送信されます。

つまり、セキュリティイベントログとは別物となるため、セキュリティベンダーの監視に利用できるログではありませんでした。
そのため、SIEMを利用した転送方法は断念することとなりました。

さいごに

V1ESで、セキュリティイベントを２箇所に転送する方法をまとめてみました。
この記事がどなたかのお役に立てれば嬉しいです。

以上、クラウド事業本部の吉田でした！