Datadog Cloud SIEMを使ってAWS環境の脅威を可視化した話/lifeistech-datadog-cloud-siem

Datadog Cloud SIEMを使って AWS環境の脅威を可視化した話     2024.07.17

2 登壇者と  ライフイズテックの紹介  

＜過去の職歴＞   • SI営業  • WEB制作（HTMLコーダー、WEBディレクター）  • プリセールス（ホスティングサービス）   •
インフラエンジニア（オンプレミス /クラウド）  ＜好きなDatadogサービス＞   • Datadog Logs  • Datadog Cloud SIEM  自己紹介  3 ライフイズテック株式会社  サービス開発部インフラ/SREグループ所属  栁田順也（ぎだじゅん）   X： https://twitter.com/gdjn2023   note: https://note.com/gidajun/ 

4 ライフイズテックのご紹介①   世界を変える力を、すべての人に。   中高生向け（ ITワークショップ）   • Life
is Tech ! Camp  • Life is Tech ! School  大学生向け（デジタルスキル育成・研修）   • Life is Tech ! Leaders  社会人向け（デジタル人材育成研修）   • DX Readiness  学校・塾向け (EdTech教材）  • Life is Tech ! Lesson  • Life is Tech ! Lesson for 学習塾 

5 ライフイズテックのご紹介②   Life is Tech ! Lesson は主にAWS上で稼働しています。  
https://life-is-tech.com/news/news/220816-media https://aws.amazon.com/jp/solutions/case-studies/lifeistech-aws-is-how/

6 アジェンダ   • SIEMの導入の背景  • SIEM環境にDatadogを選んだ理由  • Datadog Cloud
SIEMを使った脅威の検出と運用  • Datadog Cloud SIEM導入時の課題と対策  • まとめ 

7 SIEMの導入の背景  

8 ライフイズテックでのこれまでのお仕事   • 2022年7月にライフイズテックにジョイン   中高生が安心して安全にサービス利用できるよう、主に自社プロダクトのセキュリティ整備を中心とした仕事に携わってきました  •
主に行ってきたお仕事   1. クラウド環境のセキュリティ態勢管理（ Cloud Security Posture Management）の導入と運用  2. SIEM（Security Information and Event Management）の導入と運用   3. プロダクトのアプリケーションのセキュリティ対策   4. 自社の情報システムのセキュリティ対策（兼任業務）     インフラエンジニアなのに   どうしてセキュリティ中心の   お仕事してるの？  

みんな安心して安全なサービスを利用してもらうためだっ！！   9 セキュリティのお仕事をする理由  

10 プロダクトのセキュリティの課題   • クラウドセキュリティ態勢管理 (CSPM)を使って、不適切な設定などがないかを洗い出して対策はできてきた  • ただし、内部や外部からの脅威に対して、コトが起こってから行動するリアクティブな状況 
◦ 各種ログは取得していたが、何か問題があったときに使う程度  ◦ インシデントが起きた時にログから調査を初めても、原因特定するまでの間に被害は拡大してしまう  • 常にどこで何が起きているかを可視化できるようにしておくことで、脅威となった箇所を早く特定できたり、攻撃の予兆を検知して早期に対策を講じることができる  セキュリティの可視化が   できる環境があれば・・・  

11 SIEMを使ってみる   ChatGPT 3.5の回答  ChatGPT 4oの回答  セキュリティ情報やイベントを統合・分析し、   リアルタイムで脅威を検出・対応するシステム
  SIEMって何？  おいしいの？  

12 一般的なSIEMの特徴  • データ統合と相関分析  ◦ 様々なソースからのログデータやイベント情報を一元管理し、それらのイベントやログデータを相関させて分析できるようにする  • リアルタイムにデータを可視化  ◦
リアルタイムのデータを視覚的に表示するダッシュボードにより、脅威の予兆や異常を一目でわかるように可視化できる  • 高度な分析による脅威の検出  ◦ 異常な動きや潜在的な脅威を検出するための高度な分析を行い、隠れた脅威を見つけだし、アラート表示や通知を行う 

13 なぜSIEMが必要か？   1. 知らないところでリソースが追加・変更・削除されている  2. 知らないところで攻撃を受けている  3. 知らないところでアカウントを不正利用されている  <＝知らないところで脅威が発生する
    「知らないところ」をなくす  

14 理想は「必要な時に必要なリソースを使える」   • 本来クラウドとは、サービス提供者と直接やりとりすることなく、必要に応じ、自動的に、コンピューティング能力を一方的に設定できること  ◦ クラウド環境なのに、必要な稟議申請と承認フローを経てリソース追加していたらクラウドの意味が薄れてしまう  •
だけど、好き勝手にリソースをつくられても管理側としては困る  ◦ 知らないところで作成されたリソースがセキュリティの脅威となりうる場合がある  いつ、だれが、どのリソースの作成/ 変更/削除をしたかを可視化   IPA 独立行政法人情報処理推進機構「 NIST によるクラウドコンピューティングの定義」より https://www.ipa.go.jp/security/reports/oversea/nist/ug65p90000019cp4-att/000025366.pdf

15 悪い奴らは常に攻撃できるとこを探してる   • 毎日、いろいろなところから攻撃の予兆が発生している  ◦ 脆弱性のありそうなパスへのリクエスト  ◦ IPに対してのポートスキャン  ◦
どんなパッケージを使用しているかなどのヘッダ情報の収集  ◦ 不正な脆弱性のスキャン  • GuardDutyなどで検出できるものは、CloudTrailやVPCフローログ、 DNSログからのもので、サービスのアクセスログ（ELBのログ）などからは脅威を検出しない  いつ、だれが、どこに対しての攻撃をしようとしているかを検出  

16 あなたのアクセスキー、漏れてません？   • アカウントやアクセスキーが不正に利用されているか？  ◦ いつもと異なるIPからリクエストがある  ◦ 特定のアカウントで大量のリクエストが発生している  ◦
短い時間で距離のある場所（IP）から同一のアカウントでリクエストの形跡がある  ◦ 権限のないイベントに対してリクエストを試みようとしている  いつ、どこから、どのアカウントを使って不正利用しているかを検出  

17 SIEM環境に  Datadogを選んだ理由  

18 過去に他の SIEM環境を使っていました   • メリット  ◦ AWS環境内にSIEM環境を導入できる  ◦ 導入が簡単（用意されたIaCのテンプレートで一発で環境を構築） 
◦ AWSのソリューションなので、AWS関連ログとの親和性が高い  • デメリット（というか我々の運用側の問題・・・）  ◦ SIEM環境自体はAWSのOpenSearch環境を使用するため、環境のリソースの調整やチューニング、アップデートの運用が面倒  ◦ ログをいろいろ投入したので、EBS（ディスク）の容量不足やデフォルト IPOSの制限に引っかかりログの取りこぼしがよく起きた 

19 Datadogの選定理由   • もともとプロダクトのサービス状態やパフォーマンスなどのオブザーバビリティとしてDatadogを利用している  ◦ ログもすでにアクセスログなどはDatadog Logsへ投入している  •
SIEM環境がフルマネージドで提供される  ◦ 環境の運用やリソース状況などを気にする必要がない！！！  （コストは気にする必要があるけど） 

20 Datadog Logsを使ったダッシュボード   • CloudTrailログで可視化したもの  ◦ 各種リソースの追加 /変更/削除  ◦
AWSコンソールのログイン成功 /失敗  ◦ アクセスキーのリクエスト成功 /失敗  • Elastic Load Balancingログで可視化したもの  ◦ HTTPステータスコードが400番台、500番台となっているリクエスト内容   （リクエスト元IP、リクエスト先ホスト、パス）   • AWS WAFログで可視化したもの  ◦ Blockされているリクエスト内容（リクエスト元 IP、リクエスト先ホスト、パス）   • VPCフローログで可視化したもの  ◦ パブリックIPからSSHやリモートデスクトップのポートへの接続情報   • Route53 Resolver クエリログで可視化したもの  ◦ VPC 内から DNS への名前解決したクエリ内容（どのホスト名を名前解決したか）  

21 こんな感じのウィジェットを作成  

22 残る課題  • Datadog Logsによるダッシュボードで状況の可視化はできたが、この状況からどのようなアクションが脅威であるのかどうやって見分ければいいのだろうか・・・  状況を可視化できても、どのような状況の場合にどんな
脅威の可能性があるのかなど、どうやって判定すればいいんだろう・・・ 

23 そこでDatadog Cloud SIEMの登場です！   https://www.datadoghq.com/ja/product/cloud-siem/

24 Datadog Cloud SIEM  を使った脅威の検出と運用  

25 Datadog Cloud SIEM とは  • リアルタイムの脅威検知   ◦ 運用ログやセキュリティログを
リアルタイムに分析し、アプリケーションやインフラストラクチャーに対する脅威をリアルタイムに検出   ◦ 自動化された相関分析と機械学習を活用して、ターゲット攻撃や脅威インテリジェンスの不正 IP、安全でない構成などを迅速に特定   • カスタマイズ可能なセキュリティルール   ◦ Datadogが厳選されたすぐに使える検知ルールを提供   ◦ 用意されているルールは、 MITRE ATT&CK フレームワークにマッピング済み   ◦ デフォルトで提供される検出ルールからクローン作成してカスタマイズも可能   • セキュリティシグナル管理   ◦ 検出された脅威はセキュリティシグナルとして記録され、詳細な観測データを相関的に要約された情報をもとにセキュリティシグナルエクスプローラーから調査できる   ◦ 検出されたセキュリティのアクティビティは 15か月前まで遡ってイベントを可視化して相関させることができる  Datadog 「Datadog Cloud SIEM」： https://www.datadoghq.com/ja/product/cloud-siem/ Datadog 「Cloud SIEM の概要」： https://docs.datadoghq.com/ja/getting_started/cloud_siem/ Datadog 「Datadog セキュリティモニタリングが新登場」：https://www.datadoghq.com/ja/blog/announcing-cloud-siem/ MITRE 「ATT&CK フレームワーク」： https://attack.mitre.org/

26 このような流れでログから脅威を検出   1. Datadogに各種ログが送信される  2. LogsのPipelinesでパースしてDatadogで使用できる形式に変換  ◦ パイプライン： https://docs.datadoghq.com/ja/logs/log_conﬁguration/pipelines/ 
3. 様々なログで同じ意味を持つ値でも異なる名称の情報を同じ属性に統一する   ◦ 属性とエイリアス設定： https://docs.datadoghq.com/ja/logs/log_conﬁguration/attributes_naming_convention/  ◦ Default Standard Attributes： https://docs.datadoghq.com/ja/standard-attributes/  4. 検知ルールを使って脅威がないかを検出   ◦ ログ検出ルール： https://docs.datadoghq.com/ja/security/cloud_siem/log_detection_rules/  5. 検出された脅威は「セキュリティシグナル」として作成され、検出された内容の詳細を確認できる   ◦ セキュリティシグナルの調査： https://docs.datadoghq.com/ja/security/application_security/threats/security_signals/  Indexに保持されたLog情報やAWSインテグレーションで取得したメトリクス、 Cloud SIEMのデフォルトダッシュボードから独自のダッシュボードを作成   CloudTrailログ  ELBログ  GuardDutyログ  Route 53クエリログ  ログを送信  Logs  Rules  Security  Rules  Attribute  Mapping  Log  Pipelines  Security  Signals  ①  ②  ③  ④  ⑤  Log Indexes  Dashboard 

27 Datadog Cloud SIEMの最大の特徴   • 検出ルール（ OOTB Rules）  •
セキュリティシグナル   名前だけでも覚えて帰ってね！  

28 検出ルール（ OOTB Rules）について   • 取り込まれたすべてのログとクラウド構成に適用される条件のロジックを定義して作成されたルール  • ルールに定義されたケースに一定期間中に少なくとも
1 つ一致すると、セキュリティシグナルが生成  ◦ 「OOTB Rules」: CLOUD SIEM(LOG DETECTION)  ▪ https://docs.datadoghq.com/ja/security/default_rules/?cate gory=cat-cloud-siem-log-detection   

29 検出ルールを確認する   • Security > Detection Rules から確認できます 

30 代表的な「検出ルール」   ▪ 各種リソースの変更   ◦ S3バケットポリシー変更   ◦
IAMポリシー変更  ◦ RDS削除  ◦ セキュリティグループの作成 /変更/削除、インバウンドルールでの全公開、データベースポートのパブリック公開   ◦ S3パブリックアクセスブロックの削除   ◦ SecurityHub/Conﬁg/CloudTrailの無効化  ◦ WAFのWebACL変更/削除  ◦ VPCの各種変更  （VPCの作成、ルートテーブルやネットワークゲートウェイの作成 / 変更、サブネットの削除など）   ◦ CloudWatchロググループの削除やルールの無効化 /削除  ◦ KMSキーの削除  （削除スケジュールの設定）   ◦ EventBridgeのルール変更や削除   ▪ 不用意な公開 /流出や漏洩の疑い   ◦ AMIの公開  ◦ EBSスナップショットの公開、漏洩の可能性  ◦ RDSスナップショットの流出の可能性   ▪ 異常な数のアクティビティ   ◦ IAM AssumeRoleに対しての異常な数のアクティビティ   ◦ S3バケットに対しての異常な数のアクセス   ◦ ユーザからAWS APIコールでの異常な数の AccessDenied エラーを受信  ◦ EC2インスタンスからの異常な AWSイベントの実行  ◦ AWS Secrets Managerへの異常な数のシークレット情報の取得  ▪ 侵害の疑い   ◦ EC2インスタンス  ◦ IAMアクセスキー  ◦ AWS 環境内で識別された Tor クライアント IP アドレス  ▪ AWS ConsoleLogin  ◦ ConsoleLoginに対するブルートフォース攻撃の可能性   ◦ MFAなしのAWSコンソールログイン   ◦ ルートアカウントによるアクティビティ   ▪ その他  ◦ Log4Shell スキャンの検出   ◦ セキュリティスキャナからの HTTPリクエスト 

31 検出ルールのカスタマイズ   • サービスの要件などで問題ないものでもデフォルトの検出ルールに引っかかってしまうものは、検出ルールをクローンして、抑制条件をクエリに追加修正して既知の検出を除外したり、検出の要件をクエリ追加して検出条件をより絞ったりできる。  

32 AWS以外の検出ルールも豊富   • AWSの監査ログ（CloudTrail）以外に、 Azure SecurityやGCP Audit Logs、 Kubernetes
Audit Logsの検出ルールも用意されている  • Apacheやnginx、IISのログから、セキュリティスキャナからのHTTPリクエストの検出ルールやネットワーク関連（ Cisco Meraki、Cloudﬂare、Palo Alto）の検出ルールもある  • Microsoft 365やGoogle Workspace、 Slack用の検出ルールや1password、 Okta、Oneloginなどの認証サービス用の検出ルールもある  （情報システム部門などで使えそう） 

33 セキュリティシグナルについて   • 検出ルールに一つでも該当する脅威が検出されると「セキュリティシグナル」が生成される  • 重大度や発生時期、シグナルをトリガーするすべてのログの情報を関連づけて要約したもの  ◦
潜在的な脅威をすばやく選別し、システム内に潜む設定不良や攻撃の可能性についての調査ができる  ◦ 対象のシグナルに対して調査を依頼するユーザー（Datadogのユーザアカウント）の指名や、調査のステータスを更新するなど、対応についての状況管理ができる 

34 セキュリティシグナルを確認する   • Security > Signals Explorer から確認できます 

35 セキュリティシグナルの内容   • Overview  ◦ 関連するアクティビティが発生した時系列グラフ、脅威として検出されたアクティビティを実行したアイデンティティ（IAM USER
/ Assumed Rolesなど）やIPなどのエンティティ情報、検出したログに含まれるリクエスト元 IP、ユーザアイデンティティ、イベントソースやイベント名などのコンテキスト情報などの概要を確認  • Rule Details  ◦ ログからどのような条件で検出されたかや、トリアージ方法のヒントを解説  • Logs  ◦ 検出ルールに該当したログをリスト表示   • Related Signals  ◦ 該当のシグナルの条件と該当のエンティティ情報が同じものを関連のシグナルとしてリストアップ   • Suggested Action  ◦ 推奨アクションとして、調査をする上で参考となるダッシュボードや推奨クエリを使ったLogsでの表示への遷移を紹介  ◦ アイデンティティなどのエンティティ情報から他にも不審なアクティビティが行われていないかを可視化できる「Investigator」へリンク 

36 セキュリティシグナルの要約を見る①   Anomalous amount of access denied events for
AWS EC2 Instance を例に説明   ▪ Overview  ◦ 検出された概要を説明  ➢ どのようなユーザやアクティビティで異常を検出したかのグラフや、検出した内容に関連するソース情報やリクエスト元のIP、IAM USER / Assumed Roles などのユーザアイデンティティ、イベント名、インスタンスID、関連タグ情報などのコンテキスト、検出されたエンティティやIP情報を確認できます。  ➢ コンテキスト情報から関連する他のリクエスト状況などをLogsでフィルタ設定して表示されることも可能  ➢ 下の「JSON」では検出された内容をJSON形式で表示  該当の脅威がいつ何をしていたかの情報や、それらがどこのIPから行われていたか、どのような権限を使って実施していかかを確認できます  

37 セキュリティシグナルの要約を見る②   Anomalous amount of access denied events for
AWS EC2 Instance を例に説明   ▪ Rule Details  ◦ 検出ルールの内容を説明  ➢ どのログで、どのような条件で検出したかの「Strategy」や、どのような判断や対応をすればよいかのヒントとなる「Triage and response」などを説明。  ➢ この検出では「AWS EC2 インスタンスでのアクセス拒否イベントの異常な数の検出」として、CloudTrail ログを監視して、 EC2インスタンス (@userIdentity.session_name:i-*) で異常な量のAccessDeniedとなったイベントがあったため、検出ルールに該当となり、セキュリティシグナルが作成されている  どのような条件でログから検出されたかを確認したり、トリアージするにあたって何を見ればよいかのヒントを確認できます  

38 セキュリティシグナルの要約を見る③   Anomalous amount of access denied events for
AWS EC2 Instance を例に説明   ▪ Logs  ◦ 検出ルールに該当したログをリスト表示  ➢ 該当のログをクリックすると、Logsで見れるようなログの詳細を確認できます。  • こちらの一覧からはLogsの保持期間に関係なく、15ヶ月前までのログがみれる  ➢ 「View All Related Logs」をクリックすると Logsの画面に遷移して、検出されたフィルタの状態でログの一覧を表示したり、 CSVなどの形式でダウンロードもできる  • ただしLogs側で表示できるログは、 Logsの保持期間までのログのみとなります  該当のアクティビティがどれくらい発生していたかや、アクティビティ単位でどのようなことが行われていたかの詳細をログから確認できます  

39 セキュリティシグナルの要約を見る④   Anomalous amount of access denied events for
AWS EC2 Instance を例に説明   ▪ Related Signals  ◦ 関連するシグナルを時系列表示  ➢ 該当のシグナルの条件フィルターと該当エンティティ情報（IAM USER/Assumed RolesのARN、セッション名、AWSアカウントID、リクエスト元IPなど）が同じものを関連のシグナルとしてリストアップ  同様の脅威がどのような時間と頻度で発生していたかを確認できます  

40 セキュリティシグナルの要約を見る⑤   AWS security group created, modiﬁed or deleted
を例に説明   ▪ Suggested Action  ◦ 調査をする上で参考となるダッシュボードやLogsでの推奨クエリを紹介  ➢ DASHBOARDSからは、Cloud SIEMの標準ダッシュボードを使って、該当エンティティ情報（IAM USER / Assumed RolesのARN、セッション名、AWSアカウントID、リクエスト元IPなど）に関連する情報を表示  ➢ INVESTIGATION QUERIESからは、該当エンティティ情報に関して、他にどのような形跡があったかをLogs から調査できるように、推奨するクエリで表示できる Viewリンクを用意  ➢ AWSの「Investigate with Cloud SIEM Investingator」では、該当エンティティ情報（IAMユーザ/ロールのARN、セッション名、AWSアカウントID、リクエスト元IPなど）による行動をグラフィカルなインターフェースで表示します。  該当のエンティティ情報が、検出された脅威の前後でなにを行っていたかを Logsから調査できるようにしたり、他にどのようなイベントを実施していたかを Investingatorで調べれるように遷移してくれます  

41 Investigatorで不審なアクティビティを確認   ▪ 検出ルールで検出された該当のエンティティ情報（IAM USER/Assumed RolesのARN、アクセスキーIDなど）にて、他にも不審なアクティビティが行われていないかを可視化できるグラフィカルインターフェイスを提供  ◦
ユーザーが他のアカウントにアクセスしていないか？   ◦ その特定の時間帯に、ユーザーは他にどのようなアクションを起こしたのか？   ◦ ユーザーがリソースに対して行うすべてのアクションは何か？  ◦ どのようなユーザーがこのリソースと交流しているのか？   ▪ Security > Cloud SIEM を開き、Investigatorタブからも確認もできます  Datadog 「Investigator」： https://docs.datadoghq.com/ja/security/cloud_siem/investigator/ Datadog 「Datadog Cloud SIEM Investigator で履歴セキュリティ調査を実施する」： https://www.datadoghq.com/ja/blog/cloud-siem-historical-investigations/

42 デフォルトで用意された Cloud SIEMダッシュボード   • Cloud SIEMでは、セキュリティに関するレポートやモニタリングですぐ使えるデフォルトのダッシュボードを用意  ◦
Cloud SIEM画面の左上にある Dashboardsのプルダウンから、デフォルトで用意されているダッシュボードを選択することができます。   ◦ Dashboards「Cloud SIEM Overview」  ◦ 該当の数値を右クリックして「 View related Security Signals」を選択すると、該当のセキュリティシグナルの一覧へ遷移できます  

43 Datadog Cloud SIEMを使った運用   ▪ デイリーでダッシュボードから検出内容をチェック  • セキュリティシグナルの内容を確認し、既知の作業によるものか、攻撃の可能性があるかなどをトリアージ 
◦ 緊急性の高いものについては、随時対応を実施、または関係各所に連絡をとり、対応内容などを協議  ▪ セキュリティシグナルの重要度が「CRITICAL」と「HIGH」については、Slackチャンネルに通知して、リアルタイムで確認を行う  • 通知は Security > Cloud SIEM > Settings から設定  ▪ 週次で関連チームへセキュリティレポートとして状況を関係各所へ報告 

44 レポート作成の運用   • Logsから作成したウィジェットとCloud SIEMのダッシュボードからのウィジェットを組み合わせて、オリジナルのSIEMダッシュボードを作成  • 毎日0時（AM 12:00）にデイリーレポートとしてPDF形式で出力したレポートを指定のメールアドレスに送信 
◦ Dashboardsの「Conﬁgure」にある「Conﬁgure report」からレポートの送信設定できます  

45 Datadog Cloud SIEM  導入時の課題と対策  

46 Datadog Cloud SIEMの分析対象はすべてのログ   • Cloud SIEMで分析をする対象のログはデフォルトでは、 Datadogに取り込まれるすべてのログが分析対象
  ◦ Cloud SIEMで分析されたログのイベント数が課金対象   ◦ CloudTrailのログからのみ脅威の検出をされていても、他のログが Datadog に取り込まれている場合は、デフォルトではそれらのログも課金対象となる   デフォルトではすべててのログが検出ルールに流れてくるので、   すべてのログを分析します(結果に関係なく課金対象)  # こちらは昨年の時点の内容で、現在は料金プランが異なっている可能性もあるため、料金に関しての詳しい話は Datadogの担当者の方にお問い合わせください。 noteにまとめてあるので   よかったらみてね！   Datadog Cloud SIEMを利用してみた＆ちょっとしくじった話 https://note.com/gidajun/n/n459a4a670a5f

47 Datadog Cloud SIEMに必要なログ   • CloudTrailログ以外にもアプリケーションログなどを配信していたが、アプリケーションログの内容からCloud SIEMの検出ルールで検出されるケースがほとんどない（あくまで弊社の場合） 
• Cloud SIEMで分析する対象のログを絞りたい  Cloud SIEM API によるセキュリティフィルター   で分析対象のログを絞る   • Cloud SIEM APIでセキュリティフィルターを設定して、取り込んだログのどのサブセットを分析するかを指定できる   • セキュリティフィルターは DatadogのWEB画面からではなく、 Cloud SIEM APIに対して curl などを使ったコマンドラインでリクエストを送る形式で設定   Datadog 「Cloud SIEM API によるセキュリティフィルター」： https://docs.datadoghq.com/ja/security/cloud_siem/guide/how-to-setup-security-ﬁlters-using-cloud-siem-api/

48 セキュリティフィルターによる分析対象ログ制御   • Cloud SIEM APIによるセキュリティフィルター設定の手順  1. DatadogのAPIキーとアプリケーションキーを用意する 
(Organization Settings > ACCESS > Application Keysで作成)  2. 現在のフィルターの設定を確認する  (curlコマンドによるAPI callでの設定)  3. カスタムフィルターを追加作成する  (curlコマンドによるAPI callでの設定)  4. デフォルトのセキュリティフィルターを無効化する  (curlコマンドによるAPI callでの設定)    Zennにまとめてあるので   よかったらみてね！   【Datadog】Cloud SIEMの有効化とセキュリティフィルターによる分析対象ログ制御 https://zenn.dev/gidajun/articles/29ec4adeb9dfaa

49 セキュリティフィルターによる分析対象ログ制御   現在のフィルターの設定を確認する   API call  curl -L -X
GET 'https://api.datadoghq.com/api/v2/security_monitoring/configuration/security_filters' \  --header 'Content-Type: application/json' \  --header 'DD-API-KEY: <DATADOG_API_KEY>' \  --header 'DD-APPLICATION-KEY: <DATADOG_APP_KEY>'  Response  {  "data": [  {  "attributes": {  "is_enabled": true,  "is_builtin": true,  "name": "all ingested logs",  "filtered_data_type": "logs",  "exclusion_filters": [],  "version": 1,  "query": "*"  },  "type": "security_filters",  "id": "l6l-rmx-mqx"  }  ]  }  • data.name にはデフォルトのフィルター名「 all ingested logs」が記載されており、data.filtered_data_type は「logs」なのでフィルターのデータタイプは Logsのデータを対象とし、data.query にはすべてのログを対象とするため「 *　(ワイルドカード)」が指定されている  • data.is_enabled の値は「true」となっており、このセキュリティフィルターが有効な状態であることを示している   • data.id にはセキュリティフィルター毎に任意のフィルター ID情報（例では「l6l-rmx-mqx」）が設定され、後述のフィルターの設定変更をする場合はこのフィルターIDを指定して変更を行うので控えておいてください。 

50 セキュリティフィルターによる分析対象ログ制御   カスタムフィルターを追加作成する   API call  curl -L -X
POST 'https://api.datadoghq.com/api/v2/security_monitoring/configuration/security_filters' \  --header 'Content-Type: application/json' \  --header 'DD-API-KEY: <DATADOG_API_KEY>' \  --header 'DD-APPLICATION-KEY: <DATADOG_APP_KEY>' \  --data-raw '{  "data": {  "type": "security_filters",  "attributes": {  "is_enabled": true,  "name": "cloudtrail elb guardduty route53",  "exclusion_filters": [],  "filtered_data_type": "logs",  "query": "source:(cloudtrail OR elb OR guardduty OR route53)"  }  }  }'  Response  {  "data":[  {  "id":"l6l-rmx-mqx",  "attributes":{  （〜省略〜）  },  "type":"security_filters"  },  {  "id":"qw3-spe-wsx",  "attributes":{  "version":1,  "name":"cloudtrail elb guardduty route53",  "query":"source:(cloudtrail OR elb OR guardduty OR route53)",  "is_enabled":true,  "exclusion_filters":[],  "filtered_data_type":"logs",  "is_builtin":false  },  "type":"security_filters"  }  ]  }  • 追加するフィルターでは CloudTrail 、 ELB 、 Guardduty 、 Route53 のみをCloud SIEMでの分析対象とするため、 query の値を「source:(cloudtrail OR elb OR guardduty OR route53) 」と指定  • 結果としてデフォルトのセキュリティフィルターの下に、カスタムのセキュリティフィルター「cloudtrail elb guardduty route53」が追加され、2つのセキュリティフィルターが存在していることが確認できる  

51 セキュリティフィルターによる分析対象ログ制御   デフォルトのセキュリティフィルターを無効化する   •   API call  curl
-L -X PATCH 'https://api.datadoghq.com/api/v2/security_monitoring/configuration/security_filters/l6l-rmx-mqx' \  --header 'Content-Type: application/json' \  --header 'DD-API-KEY: <DATADOG_API_KEY>' \  --header 'DD-APPLICATION-KEY: <DATADOG_APP_KEY>' \  --data-raw '{  "data": {  "attributes": {  "is_enabled": false  },  "type": "security_filters"  }  }'  Response  {  "data":[  {  "id":"l6l-rmx-mqx",  "attributes":{  （〜省略〜）  "is_enabled":false,  （〜省略〜）  },  "type":"security_filters"  },  {  "id":"qw3-spe-wsx",  "attributes":{  "version":2,  "name":"cloudtrail elb guardduty route53",  "query":"source:(cloudtrail OR elb OR guardduty OR route53)",  "is_enabled":true,  （〜省略〜）  },  "type":"security_filters"  }  ]  }  • API callで指定するURLのパス部分では、最初に確認したデフォルトのフィルター ID情報（例では「l6l-rmx-mqx」）を指定し、data.is_enabled の値を「false」で指定することで無効化する   • 結果としてデフォルトのセキュリティフィルター（例では「 l6l-rmx-mqx」）の data.is_enabled の値は「false」となり、追加したカスタムフィルター（例では「qw3-spe-wsx」）のdata.is_enabled の値は「true」のままとなり、カスタムフィルターのみが有効になりました   • このカスタムフィルターで設定されている Datadog Logsの「source」が「cloudtrail」、「elb」、「guardduty」、「route53」のいずれかに該当するログのみが Cloud SIEMでの分析対象となりました  

52 セキュリティフィルターで対象を絞れたか確認   • Datadogの「推定使用量メトリクス」の「分析ログ (セキュリティ)/ソース別」のメトリクスで、対象のソース別の使用量を確認できます  datadog.estimated_usage.security_monitoring.sources.analyzed_bytes 

53 まとめ 

54 Datadog Cloud SIEM の特徴  • 利用開始はログをDatadogに送ってDatadog Cloud SIEMを有効にするだけ 
• すぐに使える厳選されたセキュリティルールで脅威を検出してくれる（カスタマイズも可能）  • 検出された脅威はセキュリティシグナルとして15か月間保持  ◦ セキュリティシグナルでは、詳細な観測データを相関的に分析した内容を要約してくれる 

55 Datadog Cloud SIEMを導入して実現できたこと   • インシデントの早期発見  ◦ 予兆の検知や見えなかった脅威の可能性などが早期に発見でき、迅速な対応が可能になった 
• 自動化された脅威検出  ◦ 検知した内容の詳細が関連する複数のログの情報を関連性づけて要約してくれるので、手作業での原因究明の手間が減り、効率化された  • マネージドサービスにより環境の運用がなくなった  ◦ セキュリティ運用に専念ができるようになった 

56 さぁ、みんなも Cloud SIEMを有効にしよう！？   • Zennで有効にする手順や、セキュリティフィルターの設定方法など書きましたので参考にしてください！  （昨年9月時点のものなので、実際の内容が変わっていたらごめんなさい）  https://zenn.dev/gidajun/articles/29ec4adeb9dfaa 

Datadog Cloud SIEMを使ってAWS環境の脅威を可視化した話/lifeistec...

Datadog Cloud SIEMを使ってAWS環境の脅威を可視化した話/lifeistech-datadog-cloud-siem

Other Decks in Technology

Featured

Transcript