こんにちは！技術本部情報セキュリティ部 CSIRTグループ所属の吉山です。普段の業務では、AWSをはじめとする各種クラウド環境のセキュリティ向上・統制やSIEM基盤の開発・運用などに向き合っています。

今回は、昨年12月〜今年2月頃にかけて行った新SIEM基盤の導入・移行について、1年経ったので振り返りとして記事にまとめていきたいと思います。

本記事はSansan Advent Calendar 2024 - Adventar8日目の記事です。

移行開始までの道程
- SIEM on AOSが抱えていた課題
- なぜSplunkを選んだのか
移行中のお話
稼働開始後
これから
最後に

移行開始までの道程

Sansan CSIRTでは、2020年頃からAmazon OpenSearch Serviceを使ったSIEMであるSIEM on Amazon OpenSearch Service（SIEM on AOS）の運用を行っていました。

github.com

SIEM on AOSも良いプロダクトではありましたが、運用などを行っていく上でいくつか課題が見えてきたため、別基盤への移行を検討し始めました。

SIEM on AOSが抱えていた課題

SIEM on AOSでは、ECS*1と呼ばれるスキーマに従い、ログの正規化を行えます。これにより、複数ログ種の串刺し検索などが可能です。一方、この検索ロジックを検知に落とし込もうとした時、次のような問題が発生しました。

複数のログ種やイベントを元にした検知ルールの実装ができない
- 例）ログ種Aで〇〇というイベントが起きてからX分以内にログ種Bで△△というイベントが同一ユーザーで発生している
- 検索する際は人間が目で関連付けの判断ができるが、これをクエリに落とし込み検知ルール化することが難しい
検索クエリの記述が難しい、かつメンテ性が低い
- 基本的にJSONで検索クエリを記述するが、長く複雑で人間が直接記述することやメンテすることが難しい
  - Detection Engineeringといった検知改善の運用を回す上で障壁となる
- PPL*2といった新しい構文も導入されていたが、（少なくとも旧基盤を利用していた頃は）機能不足な点が目立った
  - ネストしたログの検索がうまく行えない、など

特に前者の問題は高度な攻撃者を想定したセキュリティ体制を築いていく上でネックなポイントでした。

こういった問題点については、自力で機能拡張やインターフェースを実装すれば、ある程度は解決できるかもしれませんが、開発や運用により大きなコストが掛かります。そこで、現状の基盤を利用し続けるより専用基盤などへ移行する事で、より本質的なセキュリティ向上にコストを割けるようにすべきと考え、別基盤への移行・検討へ舵を切りました。

なぜSplunkを選んだのか

Splunk以外のベンダが提供するSIEMソリューションについても比較検討を行いましたが、最終的にはSplunk Enterpriseへの移行を決断しました。

www.splunk.com

Splunkを選んだ要因としては、他基盤と比べ圧倒的に検知能力や機能面が優れている点が上げられます。

柔軟な検索クエリ
マネージドルールの豊富さ
Risk-based Alertingといった高度な検知を行うための仕組みがある
公式/非公式含めAppが豊富で拡張性が高い

実は、Splunkについては2020年以前にも1度SIEMとして導入していました。*3 そのため、上記のようなSplunkの利点などについてはある程度理解しており、以前運用していた際に抱えていた課題を解消できるかにフォーカスして検討や検証をしました。

ライセンスなどのコスト的に、現状ログ量や今後取り込みうるログ量に耐えられるか
- 以前はログ量ベースでのライセンス契約だったため、この問題が特に顕在化していた
- ログ取り込み量*4などを踏まえ検討した結果、vCPUベースでのライセンス体系が適切*5と判断した
- vCPUベースでのライセンス形態では、ライセンス費の増加がログ量に比例せずある程度ステップに変化するため、ログ量の急激な増加などに対応しやすい
検索速度の遅さやスケールのし辛さ
- 想定されるログ量や検索頻度などを元に最適なインスタンス構成を算出
- 実際に検証環境でPoCを実施した所、十分な検索パフォーマンスを発揮したため問題なしと判断

結果、SIEM on AOSで抱えている課題や以前のSplunkで感じていた課題を解消しつつ、検知のレベルを上げられると判断し、導入に踏み切りました。

移行中のお話

旧基盤と新基盤の並行稼働によるダブルコストの最小化や、より早く新基盤を使える状態とすることを目的として、1カ月という超短期での移行を目指してスケジューリングを行いました。この1カ月という短期間での基盤移行を行うため、思い切って強硬策と言えるプランを採用し移行を進めました。

旧基盤のみに存在する過去分のログは割り切り削除し、クラスタを縮退することでストレージ費などのコストを大幅削減
- SIEM on AOSの構成上、必ずS3に生ログが存在するため、このような思い切った策が取れた
できるだけ早く同等のログ取り込みを行いつつ、移行期間中の検知・調査は別に運用しているXDR基盤*6を活用することで、穴を減らす

あわせてSplunk社が提供しているProfessional Servicesへ一部の基盤構築作業を依頼しつつ、自分達はログの取り込み作業にフォーカス、と分担することで構築完了までのスピードを上げました。

稼働開始後

2月頃から新基盤の稼働開始をしてから大体10カ月ほど経ちました。その間、いくつものSIEM基盤改善や利用拡大のための取り組みを実施しました。

ログ取り込み範囲の拡大、取り込み方法の改善

Splunkでは、Add-onを使う事でログの取り込みが簡単に行えます。これにより、以前より幅広いログ種をより簡単に取り込めるようになりました。

また、過去に取り込んでいたログ群について、基盤移行当初はSIEM on AOSの構成を引き継ぎ、S3経由でのログ取り込みを行っていました。これらの取り込み方法をSplunk Add-onを使い直接収集する方式へ変更することで、取り込み経路の最適化やCIMの恩恵を受けられる状態を作りました。

CIM化の取り組み詳細については、同じくCSIRTグループの川口がSansan Advent Calendar 2024 - Adventar10日目の記事でご紹介します。

IaCや自動化の取り組み

新基盤の運用ではTerraformやAnsibleを用いたIaCの取り組みを本格化させました。 TerraformではAWSやCloudflare*7のリソースを管理し、レビュー可能な状態にしつつ設定ミスなどを防止しています。また、TerraformのPlan/Applyも自動化することで、デプロイ作業を容易に行える状態にしています。

AnsibleではSplunkのApp/Add-onのバージョンアップや各種設定ファイルの管理を行っています。これにより、アプデ時の手動作業を極力減らし安全にSplunkのコアやAppのアップデートが行える状態になっています。 Ansibleの活用はまだ取り組み始めたばかりの領域ですが、今後も範囲拡大や自動化などを行っていく予定です。

Detection Engineering運用

Sansan CSIRTでは、Detection Engineeringを「検知の仕組みを継続的に改善し、有効な検知ルールをデリバリーする取り組み」と定義しています。このDetection Engineeringを行うことで、SIEM基盤移行の目的である検知の高度化の実現を目指しています。現在は、マネージドルールの有効化や独自の検知ルール作成、各種検知ルールのチューニングに取り組むことで、検知のレベルを向上させています。

マネージドルールや独自のルールを含め、検知ルールを単純に有効化しただけでは、過検知が多発し運用に支障をきたします。そこで、Risk-based Alertingの活用などを進めることで、高度な侵害事象も捉えられる状態を確立しつつ、いわゆる検知担当の運用疲れの軽減も図っています。