DatadogセミナーでCloud SIEMについてお話しました
暑いのが苦手な「ぎだじゅん」です。
基本的に汗っかきで夏でも冬でも汗をかきがちです。
汗っかきにとってTシャツの色選びは難しく、色が淡いものを着ると、汗をかいたときに濡れた個所の色が濃くなって、ちょっと恥ずかしいことになったり、逆に色が濃いものを着ると、夕方ぐらいに汗が乾いて白い模様(汗で塩を吹いてできるやつ)が浮き出てきて、ちょっと恥ずかしいことになったりします。
じゃぁ、白いTシャツ着ればいいじゃんって言われたりするのですが、体型的に胸あたりを結構汚してしまいがちで、白いTシャツを着るのには勇気がいります。
他の汗っかきエピソードでは、昔、プリセールスをしていた頃に、真夏の暑い日に客先へ提案に行きましたが、部屋はエアコン効いているのに、お客様のテーブルの上に自分の額から垂れ落ちる汗で水たまりができて、お客様は私の提案よりも水たまりを気にしていたことがありました。あの時は本当にすみませんでした・・・。
本題です。
Datadogのイベントに登壇させていただきました
過去にnoteでDatadogに関する投稿をしたところ、Datadog Japanの公式Xで紹介していただきました。
その流れで、お世話になっている担当者の方から、Datadog Cloud SIEMに関する事例について登壇してみませんかとお声がけいただき、先日以下のイベントでお話させていただきました。
Datadog セミナー:事例から学ぶ Cloud SIEM とアプリケーションモニタリングの活用方法
これまで、noteを見ていただけた方からLTなどのお声をかけていただくことはありましたが、20年前に某セミナーで登壇した時のトラウマや、最新のIT関連の単語などに弱く(?)、話し方もくどい(?)とよく言われてたので、お断りしていました。
ただ、私の所属するインフラ/SREのチームでの業務もたくさん増えてきてメンバー募集が急務となり、今回お声がけいただいたタイミングがちょうどよく、所属チームの仕事のアピールも必要と思い、悩んだ結果、登壇することにしました。
お話した内容
今回、Datadog Cloud SIEM に関して実際の導入から得られた知見、ノウハウ等について話してほしいとお題をいただきました。
ついては「Datadog Cloud SIEMを使ってAWS環境の脅威を可視化した話」というタイトルで、ライフイズテックのEdtech関連のプロダクトが稼働しているAWS 環境において、セキュリティ対策の一環としてDatadog Cloud SIEM を導入した背景や、どのように使っているか、導入時の課題と対策についてお話ししました。
以下が登壇の資料になります。
ざっくりまとめると以下のような内容です。
(この内容を45分かけてじっくり?お話させていただきました)
ライフイズテックでの自分の仕事
インフラ/SREグループに所属して自社プロダクトのセキュリティ整備を中心に以下の対策を行ってきた
クラウド環境のセキュリティ態勢管理(Cloud Security Posture Management)の導入と運用
SIEM(Security Information and Event Management)の導入と運用
プロダクトのアプリケーションのセキュリティ対策
自社の情報システムのセキュリティ対策(兼任業務)
プロダクトのセキュリティの課題
クラウドセキュリティ態勢管理 (CSPM)を使って、不適切な設定などがないかなどの洗い出しと対策はできてきた
しかし、内部や外部からの脅威に対して、ログは保管しているが、問題が起こってから行動するリアクティブな状況
このままでは原因特定するまでの間に被害が拡大してしまう恐れがある
どこで何が起きているかを可視化できるようにしておく必要がある
SIEMの導入が必要
SIEMとは、セキュリティ情報やイベントを統合・分析し、リアルタイムで脅威を検出・対応するシステム
SIEMを導入して、以下のような「知らないところ」で発生している脅威を見えるようにする
知らないところでリソースが追加・変更・削除されている
知らないところで攻撃を受けている
知らないところでアカウントを不正利用されている
SIEM環境にDatadogを選んだ理由
以前はOpenSearchをベースにしたAWSのSIEMソリューションを使っていたが、OpenSearchの環境の運用などで苦戦していた
もともとプロダクトの状態のオブザーバビリティとしてDatadogを利用していた知見や、Datadogがフルマネージドな環境であることから、Datadog LogsとDashboardの機能を使って、OpenSearchのSIEM環境とほぼ同様のダッシュボードを作成
ただ、ダッシュボードだけではリアルタイムでの脅威の検出はできず、ログからどのようなアクションが脅威と判定するかの見分け方や検出機能が必要
Datadog Cloud SIEMも導入してみた
Datadog Cloud SIEM とは
ログから脅威を検出するための「検出ルール(OOTB Rules)」が用意されている
各種クラウド環境のAuditログ(AWSだとCloudTrailログ)をDatadogへ送りさえすれば、デフォルトで検出ルールに一致する脅威を検出してくれる
検出ルールはカスタマイズしたり、独自ルールを新規作成して追加も可能
検出ルールに一つでも該当する脅威があると「セキュリティシグナル」が生成される
「セキュリティシグナル」では重大度や発生時期、脅威に関連するログ情報を紐づけして要約してくれる
Logsなどと連携して、脅威をうけた認証情報などに関連するログをリストアップして、脅威を受ける前の経緯などを深掘りできる
セキュリティシグナルのアクティビティは15か月前まで記録される
Datadog Cloud SIEM導入時の課題と対策
Datadog Cloud SIEMで分析対象(=課金対象)となるログは、デフォルトではDatadogに流れてくるすべてのログが対象
脅威を検出できるログであるかどうかに関係なく、Datadogに送られてきたログはすべて課金対象となる模様
Cloud SIEM API によるセキュリティフィルターを使って、Datadog Cloud SIEMの分析対象とするログの種類を絞ることが可能
DatadogのAPIキーとアプリケーションキーを使ってcurlコマンドでAPIへリクエストする
カスタムフィルターを設定し、デフォルトのフィルターを無効化することで制限できる
Datadog Cloud SIEMを導入して実現できたこと
インシデントの早期発見
予兆の検知や見えなかった脅威の可能性などが早期に発見でき、迅速な対応が可能になった自動化された脅威検出
検知した内容の詳細が関連する複数のログの情報を関連性づけて要約してくれるので、手作業での原因究明の手間が減り、効率化されたマネージドサービスにより環境の運用がなくなった
セキュリティ運用に専念ができるようになった
これらの内容は、主には過去にnoteやZennに投稿した以下の内容をまとめた感じになっていますので、よかったらこちらも見てみてください。
登壇後にお話聞きました
登壇後にネットワーキング レセプションとして、セミナーにご参加いただいた方々とお話をする時間がありました。
そこでお話した中で、SIEMの必要性はわかっていらっしゃる方は多かったものの、SIEMの導入にあたっていくつかの壁があることをお聞きしました。
SIEM導入にあたって上長の理解が得られない
ログ量によるコストが気になる
規模が大きい会社では検出したものに対してのトリアージや対応の運用リソースがかかりそう
1に関しては、おそらく2と同じコストの問題や3と同じ運用リソースなどの問題によって、導入まで踏み込めないのではと予想しています。
セキュリティ対策はコストではなく、サービス利用者に対しての安全や顧客からの信頼を守るための投資として考えるべきものと、いろんなサイトでも言われています。
ただ、なかなか上長や経営陣から理解を得られずに、挫折してしまうケースが多いかと思います。
なぜ、その投資が必要かを理解してもらうために、投資をしなかった場合どのようなリスクがあるか、問題が起きた時に事業にどのような影響があるのかや、問題が起きた時にどのようなコストが発生するかをうまく伝えて理解してもらわないと難しいものなのかもしれません。
それらについては、IPAの「セキュリティ関連費用の可視化」を参考に、巷で発生しているインシデント事象が自社でも発生しうることであることの内容や、それらが発生した場合の想定損失額などを算出するなどして、説明資料を作成することができるかと思います。
(資料があっても、説得するのがとても難しいかもしれませんが)
また、3の運用リソースや体制に関しては、セキュリティ対策を自社で運用するにはリソースが足りなかったり、セキュリティ対策の経験がある人がいないなどで、対策するための体制を組むことができないなどがあるかと思います。
正直、弊社も同じような状態であり、専任の体制や経験豊富な人材がいない状況(私もまだまだ勉強中)ですが、いろんなサービスを活用して、できるだけ少ない人的リソースで効率よく対策するための方法を模索しています。
(今回登壇して説明したDatadog Cloud SIEMも然りです)
こちらでもいろんなサービスを活用した取り組みについて紹介しています。
Datadog Cloud SIEMでの脅威の検出時のトリアージや対処なども、最初はデフォルトの検出ルールに紐づく重大度(Severity Level)やセキュリティシグナルの「Rule Details」の内容を参考に始めていき、各社のサービス影響を加味しながら重大度を調整していくことで、企業にあった運用形式ができていくのではないかなと思っています。
ただ、AWS OrganizationsでたくさんのAWS環境を運用されている企業などでは、いろいろ工夫が必要かもしれませんね。
登壇を終えて振り返り
このようなイベントでの登壇は20年以上ぶりで、あまりの緊張で最初の5分間は話をしながらうまく呼吸ができずに、意識が飛びそうになりました。
しかし、話を進めていくうちにだいぶ落ち着いてきて、最終的に持ち時間が25分だったのに45分も話をしてしまいました。
資料作成していた時から時間オーバーしそうだとは思っていましたが、このような場で話すのが慣れていなくてポイント絞って話ができませんでした。ごめんなさい。
また、イベント前に高ぶる気持ちを抑えるために、会場のビルの地下にあったラーメン屋さんでこんなすごいものをニラ唐辛子入れて食べたので、登壇中は汗が止まらず、上半身が雨で打たれたようにビショビショでした。
大変失礼しました。
そんなお見苦しい姿での登壇でしたが、Xで嬉しいコメントを見つけて、泣きそうになりました。
投稿いただいた皆様、ありがとうございました!
さらに今回の登壇資料もDatadog Japanの公式Xでリポストしていただき、たくさんの方に見ていただいたり、「いいね!」もたくさんいただけました。
ありがとうございます!!励みになります!!
最後に
今回の登壇時に、ライフイズテックを知っている方を聞いてみたところ、ほとんどいなかった状況でした。
これまでは中高生を対象としたサービスが中心であったこともありますが、会社が掲げている「世界を変える力を、すべての人に。」を実現するためには、このような場を活用して、もっといろんな人にライフイズテックを知ってもらう必要があるなと感じました。
今回のように暖かく見ていただけるかわかりませんが、また機会とネタがあれば、皆様にライフイズテックを知ってもらえるよう登壇してみたいと思いました。
(が、自分に無理のない頻度で・・・)
まだまだ知名度は低いですが、今の会社はとてもいい会社なので、興味のある方はこちらも是非ご覧ください。
(インフラ/SREメンバー大募集中です)
また、インフラSRE以外でもLLM技術及びGenerative AIを活用した学習カリキュラムのディレクターやプロダクトマネージャー(PdM)も募集しております。
すでにいくつかのLLMを使ったプロダクトを開発しており、今後もいろいろ模索しながらAIを使って教育変革を推進していくため、この新しい分野で一緒に楽しく開発していける方、是非ご応募ください。