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_configuration/pipelines/
 3. 様々なログで同じ意味を持つ値でも異なる名称の情報を同じ属性に統一する 
 ○ 属性とエイリアス設定： https://docs.datadoghq.com/ja/logs/log_configuration/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/Config/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、Cloudflare、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, modified 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の「Configure」にある「Configure 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-filters-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: ' \
 --header 'DD-APPLICATION-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: ' \
 --header 'DD-APPLICATION-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: ' \
 --header 'DD-APPLICATION-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


No content