現時点(2021年6月17日)では英語でも日本語でもそれほど情報がないGoogleが開発したSIEM(Security Information and Event Management)製品である「Chronicle」に関して、お伝えしていきたいと思います。

謎のベールに包まれたGoogleの次世代SIEM「Chronicle」を触ってみた

Kenji Tsutsumi

2021.6.18

こんにちは、堤@スリーシェイクです。

本日は、現時点(2021年6月17日)では英語でも日本語でもそれほど情報がないGoogleが開発したSIEM(Security Information and Event Management)製品である「Chronicle」に関して、お伝えしていきたいと思います。

Chronicleの特徴

  • データ容量やサーバ台数に依存しない課金モデル
  • Googleのインフラをフル活用した驚異的な検索速度と相関的なログ分析
  • シンプルな検索UI

一般的なSIEM製品の課金モデルは、「1日で処理できるデータ容量」や「サーバー台数」を採用している製品が多い。しかし、これはスケールに影響を及ぼす課金体系となっている。ビジネスが拡大していくことで、収集されるログはどんどん増えていく。ライセンス上限に達したときに、ライセンスを上位のものに変更したり、はたまたライセンスの範囲内で分析するログを限定するといった運用になってしまう。その結果、ランニングコストが予見できなくなったり、もしくは限定されたログ分析の影響で本来検知すべきセキュリティインシデントを見落とすことになってしまう。

そこで、Googleは従来から存在するSIEMのライセンス体系とは異なるモデルを提唱。細かいところはオープンになっていないので、気になる方はお問い合わせいただきたいのだが、基本的には「なるほど、それならログの量を気にせずにどんどんログを溜め込める」といったところです。これは、長年ビッグデータを扱ってきたGoogleの知見が活かされているのだと思う。

シンプルなUI

Google Chronicle ホーム画面

以前SplunkやRSA enVisionを扱ったことのある私だが、UIのシンプルさに非常に驚いた。検索窓だけ。そう、Googleの検索画面とほぼ同じ。ここにホスト名であったり、接続先ドメイン、IPアドレス、電子メールアドレス、ユーザ名、ファイルハッシュなど、検索したい対象を検索する。

通常、SIEMが活用シーンの一つとして不正アクセスやマルウェアの感染といったセキュリティインシデントが発生したときのフォレンジック調査で使われることになる。ここで例えば感染したユーザ名や端末のホスト名であったり、不正アクセスされたサーバIPアドレスであったりなど検索をかけることになるだろう。

例えば以下の画面はとあるホスト名を検索した結果の画面である。一般的なSIEMの場合、ここまでの画面を出そうと思うと結構作り込みをしないと行けないのだが、Chronicleの場合は標準でこの画面を提供している。ここでは、とあるホストのアクティビティの状況を映し出している。不審なドメインへの接続があったかどうかなどを確認する事ができる。

もちろん、従来のSIEMのように、特定の文字列を検索する「Raw Logs Search」もあるので、従来のログ検索のオペレーションも可能だ。

ログの取り込みの仕組み

ログの取り込み方法としては、大きく分けて2種類存在する。

  1. GCSやS3などのオブジェクトストレージで連携させる
  2. Chronicle ForwarderをLinuxもしくはWindowsサーバに入れて連携する

連携方法に関しては、製品によって異なるので、都度Googleのサポートに問い合わせする必要がある。ただ、対応製品は非常に多く、EDR、アンチウイルス、ファイアウォール、ロードバランサー、クラウドサービスのログ、認証サーバ、ネットワーク機器など多岐に渡る。Chronicleの強みである「容量を気にせずにどんどんデータの取り込みが可能」な課金モデルなため、とりあえずすべてのログを取り込んでみるのがいいと思う。また、Splunkなどの既存のSIEMとの連携も可能だ。

そして、あらゆるデバイスやシステムから取り込んだログは、最終的には「UDM(Unifined Data Model)」という形式でパース、インデックス化されて、Chronicle内の顧客専用の領域に保存される。各システムのログをUDMという共通のフォーマットで保存することで、Chronicle内でのデータの紐付けや検索が非常にやりやすくするメリットが有る。UDMに関しては以下のページをご参照ください。

https://cloud.google.com/chronicle/docs/unified-data-model/format-events-as-udm

セキュリティ侵害とアラートの画面

Enterprise Insightsという画面が用意されている。IOC DOMAIN MATCHESは、接続した不審なドメインおよびそのホストの一覧が表示される。IOCとは、「Indicator of Compromise(セキュリティ侵害指標)」の略称。内部のクライアントホストや管理しているサーバが不審な動きがあったかどうかをチェックできる機能と考えていただければ問題ないだろう。これも標準で用意されているインターフェースだ。不審なドメインは、Google傘下のVirusTotalやProofPoint、アメリカ合衆国国土安全保障省などのセキュリティベンダーや米国機関が公表しているリストに基づいて行っているようだ。

また、下の「RECENT ALERTS」は、独自に設定した検知ルールに引っかかったアラートを表示している。初期状態では何も検知ルールが設定されていないので、独自に設定する必要がある。これは、YARA-L というGoogleが独自に開発したアラート定義言語があり、それに基づいて定義する。YARA-Lの詳細は以下をご参照ください。

https://cloud.google.com/chronicle/docs/detection/yara-l-2-0-overview?hl=ja

また、GoogleはGitHub上にYARA-Lのサンプルファイルが多数おいているので、これをベースにアラート設定するといいと思います。

https://github.com/chronicle/detection-rules

操作してみた感想

過去にSplunkなどのSIEMの運用や構築を数年間してきた経験から申し上げると、非常にシンプルな作りで、一般的なエンジニアであれば操作して1〜2時間程度で大半の操作は理解できるのではないかと思う。アセットごとにアラートを分析できるUIを標準で搭載しているのは、良心的だと感じた。

シンプルが故に設定項目が少ない。つまり、凝ったことをするとなると、ChronicleのAPIを介して独自アプリケーションやダッシュボードを準備する必要がある。Splunkの場合は、ダッシュボードを作る機能が内部で存在していたり、マーケットプレイスやOSSでサードパーティ製のダッシュボードも用意されていたりする。

ただ、SIEM製品の一番運用の悩みであった「ログの保存」に関しては、気にする必要はない。Chronicleに関しては完全にSaaSで提供されており、バックボーンもGoogleのインフラが使用されている。まだ、Chronicleが出てきて1〜2年程度なので、今後世界中のカスタマーの要望を聞いて、進化していくことを願いたい。個人的には、ダッシュボードを独自作れる機能はほしいなと感じます。

参考リンク

https://cloud.google.com/blog/ja/products/identity-security/introducing-chronicle-detect-from-google-cloud

ブログ一覧へ戻る

お気軽にお問い合わせください

SREの設計・技術支援から、
SRE運用内で使用する
ツールの導入など、
SRE全般についてご支援しています。

資料請求・お問い合わせ