はじめに
こんにちは、ヴィエス・オカモッティです。師走は忙しいのですぐ本題に入ります。
弊社では Datadog の一機能である Cloud SIEM 機能を利用しております。導入を検討した時点で抱いた印象でもあるのですが、現時点で軽くググってみても実際の導入事例といった記事はまだ豊富には見受けられず、ささやかな情報量であってもどなたかの助けになる可能性があるかと考え、導入の経緯やメリット等をご紹介できればと思います。
Cloud SIEM とは
そもそも Cloud SIEM とはなんぞや？という方も一定数いらっしゃるかと思われますので、一次情報として Datadog 公式のドキュメントを紹介させていただきます。 ざっくりまとめてしまうと、モニタリングの対象とする情報システムにおいて、悪意あるユーザによって引き起こされた攻撃や、悪意の有無にかかわらずシステムの脅威となり得る行為を速やかに検知するための仕組みです。そのようなインシデントの発生を未然に防ぐための機能ではなく、仮に発生してしまった状況においてその発見を早期に実現し、被害の拡大を最小限に食い止めるための機能が SIEM (Security Information and Event Management)であり、 Datadog においてはその機能が Cloud SIEM という名称で提供されているというわけです。
さて、弊社はメインプロダクトである STAFF START を Amazon Web Service 上で開発、運用ささせているわけですが、だったら「それ Pla GuardDuty でできるよ！」という感想を持たれる方がおられるかもしれません。
Cloud SIEM も GuardDuty も、所定のログをモニタリングの対象として定められた検出ルールに合致したイベントを検知する、という点においては共通したプロダクトである、と理解しておりますので、そのご意見にも概ね首肯できます。
はて、ヴィエス・オカモッティの入社以前から弊社としては既に GuardDuty を有効化していたにも関わらず、なぜ Cloud SIEM を導入するに至ったのでしょうか？
導入のきっかけ
どのような企業でも、組織としての規模感や取引先様との関係性であったり、開発・運用しているサービスの成熟状況といった要因に伴って、求められるセキュリティレベルの要因が変動するタイミングがあるかと思われます。弊社としてもある時期において、 AWS のみならず弊社社員が業務において利用するような SaaS も含め、情報システム全般における広範なセキュリティレベルの統制を最小限の工数で敷く必要が生じました。
もちろんそれまでも各 SaaS において監査ログを出力させつつ、弊社なりにセキュリティレベルを担保するための運用は継続しておりました。ただ諸般の事情により、インフラエンジニアしぐさの片手間で社内情シスの人の真似事をしなければいけなかった時期があったのですが、それまでの労力が掛かる手段で外部から要求されるセキュリティレベルの担保を最短日数で実現させるというのは、なかなかのハードルが高いものでした。そのような課題にどう向き合うべきか悩んでいたタイミングで、既にシステム管理ツールとして導入していた Datadog の一機能として Cloud SIEM が存在することを知り、サービスの特性を理解した上で導入したという経緯となります。
導入の決め手
Cloud SIEM の利用にあたっては各サービスに出力させたログを Datadog に ingest させる必要があり、そのログを Datadog にスキャンさせ index された量に応じた従量課金が発生します。幸い、導入検討フェーズにおいては対象機能のトライアル利用を Datadog 社からご提案いただけまして、モニタリングを想定していたあらゆる SaaS のログ（もちろんその中には AWS の CloudTrail ログも含まれます）を全て ingest させてみた上で、スキャン量とそれに伴う発生費用がどの程度かを事前に見積ることができました。
その結果、導入することで発生し得る追加費用と得られる運用上のメリットを考慮した結果、会社として導入を決定したわけですが、決め手となった要因をいくつかご紹介します。
対応サービスと検出ルールの豊富さ
そもそも Datadog の売りといえば、見張れないシステムなど無いワン！と言わんばかりに用意された integration 可能なサービスの多様さが挙げられるかと思います。
上記リンク先で示されているのは Cloud SIEM に限らず Datadog として提携可能なサービスの一覧ではありますが、 Cloud SIEM としては導入するだけで検出が可能となる OOTB(out of the box) Rules という一群が用意されており、その対象サービスとルールが列挙されているドキュメントが以下となります。
もちろん各企業によってモニタリングさせたいサービスは異なるかと思われますが、少なくとも弊社のケースにおいては十分なカバレッジが担保されていると判断できました。結果、諸々のサービスログをモニタリング対象とさせたことで、デフォルトで用意されている Overview 画面等で横断的に各サービスの状況をモニタリングできるようになりました。
既存機能から踏襲された使用感
こちらは前述したように、一時期においてヴィエス・オカモッティという人間が半分インフラマン半分情シスおじさんという、あしゅら男爵のような振る舞いをする必要があったがゆえに刺さった点です。既にインフラマンとして Datadog の利用ノウハウをある程度蓄えることができていた状況で情シスおじさんとして Cloud SIEM の導入の必要が生じたため、例えばログ集約の方法であったり Datadog におけるログの index の概念やモニタリング設定の手法等、本来であれば一定の習得が必要なハウツーの部分となりますが、既に導入実績があったため非常にシームレスな形で設定を完了させることができました。もし仮に他の SIEM プロダクトを導入する展開となっていたら、ここで要していた工数は何倍にも膨れ上がっていたと想定されます。
強力なビジュアライズ機能
その他、トライアル利用でこれは！と感じ入った要素として情報の追跡性を上げてくれる機能の豊富さが挙げられます。
DescribeParameters失敗しすぎの図
これはヴィエス・オカモッティの直近 24 時間における AWS でのアクティビティを AWS Investigator という機能でビジュアライズした結果です。セキュリティの都合上どうしても細部はお見せできませんが、ある人間がどの IAM Role に AssumeRole し、どの API でいかなる振る舞いをしたのか、といった情報を用意にクロールできそうなことを推察いただけるかと思います。
この辺りは、例えば CloudTrail を例に挙げると Cloud SIEM に頼らずとも標準で具備されたイベント履歴の検索機能や CloudTrail Lake によるクエリ発行等による調査も可能ではありますし、ビジュアライズ機能についても公開されている SIEM on Amazon OSS 等を活用すれば類似機能は実現可能という理解です。
情報ソースは同一ですので、 頑張れば 最終的には同じ調査結果を導き出すことは可能かと思われます。しかし、例えば普段の運用面のコストがネックになることが予想されますし、有事が発生してしまった際は一刻も早い状況の把握が必要となりますので、そのようなタイミングにおける調査の効率が圧倒的に良くなることも期待できます。
おわりに
弊社としての Cloud SIEM 導入からは一定経ちましたが、幸いなことに重大なインシデントが検知されることは無く、前述した利点をありがたく享受しながら慎ましく運用を継続できております。また現時点では情報システム部門に専任の方がジョインしてくださったことでヴィエス・オカモッティも全身インフラマンとして振る舞える立場となり、 Cloud SIEM 自体の管理主管が移ったりもしているのですが、ノウハウ等の引き継ぎにあたってもこちらが Datadog ユーザであるという利点を十分に活かせることが期待できます。
今回は、先日 Findy Tools にて寄稿させていただいた Datadog 紹介記事のまるでスピンオフかのようなスタンスで Cloud SIEM の概要を紹介させていただくに留まりましたが、機会がありましたら運用面のノウハウや考慮点などもご紹介できればと思います。
Discussion