Zenn
🐶

【Datadog】Cloud SIEMの有効化とセキュリティフィルターによる分析対象ログ制御

2023/09/01に公開
AWS
Security
datadog
observability
siem
tech

はじめに

ライフイズテックではAWS環境のメトリクスやアクセスログ、アプリケーションログなどを使って、Datadogでサービスの状態やパフォーマンスなどのオブザーバビリティを高めています。
また、最近ではDatadog Cloud SIEMの利用を開始し、プロダクトで利用しているAWS環境への攻撃やそれを予兆する通信、知らないところでの構成変更など、アプリケーションやインフラに対する脅威となりそうな状況をリアルタイムに検出するサービスを利用しています。

今回、Datadogは利用しているけどCloud SIEMの機能はまだ利用していないようなケースで、SIEMで必要なCloudTrailなどのログなども追加してCloud SIEMの機能を有効化した内容をまとめてみました。

また、Datadog Cloud SIEMは、デフォルトではDatadogに流れてくるすべてのログが分析対象となるため、Datadog Cloud SIEMでの脅威検出と直接関係しないログについても課金対象となることから、Cloud SIEMでの分析対象のログのみをフィルタリングする設定をすることで、課金対象から外して不要なコストを削減しました。
そのフィルター設定（ Cloud SIEM API によるセキュリティフィルター ）についても紹介します。

Datadog Cloud SIEMについて

Datadog Cloud SIEM については以下をご覧ください。
https://docs.datadoghq.com/ja/security/cloud_siem/

Datadog Cloud SIEM (Security Information and Event Management) は、開発、運用、セキュリティチームを 1 つのプラットフォームでつなげます。1 つのダッシュボードに DevOps コンテンツ、営業用メトリクス、そしてセキュリティコンテンツを表示。アプリケーションおよびインフラストラクチャーへの標的型攻撃、システムと通信する脅威インテリジェンスにリストされた IP、安全でない構成などの脅威をリアルタイムに検出し、セキュリティに関する問題をメール、Slack、Jira、PagerDuty、または Webhook を使用してチームに通知します。

Cloud SIEMの利用開始方法

既にDatadogのインテグレーションやログ収集を利用している環境にCloud SIEMの機能を有効にし、AWSの監査ログとなるCloudTrailのログを追加で取り込むまでの流れを紹介します。

①Cloud SIEMの有効化

Cloud SIEMの有効化は非常に簡単です。
Datadogのメニュー「Security > Cloud SIEM」のCloud SIEM画面、またはこちらの Datadog Securityスタート画面 からアクセスして、「Enable Cloud SIEM」や「Get stared」をクリックすることでCloud SIEMの機能が有効化になります。

  • Cloud SIEM画面の場合は「Enable Cloud SIEM」を押す
    Cloud SIEM画面
    Cloud SIEM画面
  • Datadog Securityスタート画面の場合はCloud SIEMの箇所で「Get stared」を押す
    Datadog Securityスタート画面
    Datadog Securityスタート画面

<有効化後のCloud SIEM ホーム画面>

有効化すると、Datadogに取得されているすべてのログから分析を行い、Datadogの分析ルール（OOTB Rules）にて検出されたセキュリティシグナル情報や対象のリソースやIP情報などの概要がCloud SIEMのホーム画面に「Security Overview」として表示されます。

Detect and respond to threats in your environment
Cloud SIEMのホーム画面（Overview）

また、この後の必要な設定も基本的には画面上にある「Get started with Cloud SIEM」でチェックボックス形式で表示されており、ここの内容を設定していけばCloud SIEMの設定が網羅できます。
（このキャプチャでは設定チェック済みのためチェックボックスが緑でチェックの入った状態になっていますが、未チェックの場合はチェックボックスのマークは白いチェックボックスの状態になっています。）
Get started with Cloud SIEM
Get started with Cloud SIEM

  • Invite your Security Team （セキュリティ チームを招待する）
    Cloud SIEMを利用するユーザを招待します
  • Analyze Cloud Audit Logs （クラウド監査ログを分析する）
    クラウド監査ログ（AWSの場合はCloudTrailログなど）を受信して分析します （参考:Cloud SIEM のための AWS 構成ガイド）
  • Explore Detection Rules （検出ルールを調べる）
    Cloud SIEMが受信ログを分析するときに検出ルールが適用されるので、必要に応じて抑制ルールを設定してノイズとなる検出を低減したりカスタム検出ルールを作成します
  • Review Security Signals （セキュリティシグナルを確認する）
    Cloud SIEM は、検出ルールに基づいてセキュリティシグナルを生成します。
  • Get Notified （通知を受け取る）
    通知ルールを使用してSlackやJiraのチケットなどにシグナルを転送します。重大度、タイプ、または頻度に基づいて通知を指定できます。

この中で「Analyze Cloud Audit Logs」は最低限必要な設定となりますので後述で説明します。

<Cloud SIEMのデフォルトのダッシュボード画面>

Cloud SIEMではセキュリティに関する調査、レポート、モニタリングにすぐ使えるデフォルトのダッシュボードが用意されています。
Cloud SIEM画面の左上にある「Dashboards」のプルダウンメニューから、デフォルトで用意されているダッシュボードを選択することができます。

「Dashuboards」のプルダウンメニュー
Dashuboardsのプルダウンメニュー

そのプルダウンメニューの一番下にある「View all 13 security dashboards」を選択すると、「Dashboards」へ移動してCloud SIEMに関連するデフォルトで用意されているダッシュボードを確認できます。

デフォルトのCloud SIEMダッシュボード一覧
デフォルトで用意されているCloud SIEMダッシュボードの一覧

一例として「Cloud SIEM Overview」を選択すると、CloudTrailなどのログから構成される以下のようなダッシュボードが表示されます。
Cloud SIEMによって検出された情報（シグナル）をレベル別にカウントして表示され、該当のカウント番号を左クリックして「View related Security Signals」をクリックすると、該当のシグナルの概要や関連するログに遷移して詳細を確認ができます。
（AWS環境の場合は、まずはCloudTrailなどのログの取り込みがないとあまり表示されないかもしれません）

DashBorad - Cloud SIEM Overview
デフォルトのDashBoradの一つ「Cloud SIEM Overview」

独自のダッシュボードを作成したい場合は、DatadogのDashboardの機能を使い、取得しているログやメトリクスからグラフやリストなどのウィジェットを作成してオリジナルのダッシュボードを作成することも可能です。
オリジナルのダッシュボード
こんな感じのオリジナルのダッシュボードを作成しました

②ログの取り込み

Cloud SIEMが有効化されるとDatadogに取り込まれてくるログをリアルタイムで分析して、脅威を検出してくれます。
Cloud SIEMではどのようなログから脅威を検出してくれるかは、メニュー「Security > Configuration」にあるCloud SIEMの「Log Sources」にて確認できます。
Log Sources画面
Security > Configuration の「Log Sources」画面

ライフイズテックではAWSに関連するログを主にCloud SIEMで利用しますが、AzureやGCPの監査ログや、Auth0やOkta、Oneloginなどの認証系サービスやGoogle Workspace(GSuite)、Microsoft　365、Salesforceなどの監査ログなども取り込んでCloud SIEMで分析が利用が可能です。
ApacheやNginxなどのアクセスログの分析も可能です。

<Datadogへのログの取り込みの設定方法について>

Cloud SIEMでCloudTrailのログから脅威の検出を分析するようにする手順については、以下にまとまっています。
https://docs.datadoghq.com/ja/security/cloud_siem/guide/aws-config-guide-for-cloud-siem/

または、各ログの取り込みの設定方法について、先ほどの「Log Sources」画面にある各ログの「Configure Source」をクリックするとそれぞれのログの収集方法を確認できるページに遷移できます。
Log Sources画面のConfigure Source
「Log Sources」画面の各ログの「Configure Source」からログの収集方法を確認できます

  • 他にも「インテグレーション」のページから該当のインテグレーションの「ログの収集」からも各インテグレーションのログ収集の方法について確認できます。

なお、今回の事例として、すでにDatadogへログを送るためにAWS環境側でDatadog Forwarderが稼働している場合は、Datadog ForwarderのLambda関数のトリガーの設定で対象のリソースに出力されているログの場所（S3バケットまたはCloudwatch Logs）を指定することで、Datadogへログが転送されます。

  • Lambdaのトリガー設定：S3
    Lambdaのトリガー設定：S3
    Lambdaのトリガー設定：S3の場合
  • Lambdaのトリガー設定：Cloudwatch Logs
    Lambdaのトリガー設定：Cloudwatch Logs
    Lambdaのトリガー設定：Cloudwatch Logsの場合

ログが取り込まれるとLog Sources画面の該当のログの「STATUS」が「INSTALLED」になり、「LOGS ANALYZED」に取り込まれた量のグラフが表示されます。

Log SourcesでINSTALLEDになった状態
Log SourcesでINSTALLEDになった状態

<Cloud SIEMで分析対象としているログ>

前段でも説明したとおりライフイズテックでは元々サービスの状態やパフォーマンスなどのオブザーバビリティ環境として使用していたため、ELBのログやアプリケーションのログなどをDatadogに取り込んでいましたが、Cloud SIEMを利用にあたってCloudTrailやGuardDutyなどのログも取り込みをしました。
ついては、現在以下の４つをCloud SIEMの分析対象としています。

<AWS WAFのログについて>

セキュリティ関連だとAWS WAF(v2)のログもありますが、AWS WAFのログはDatadogでブロック状況をダッシュボードで可視化するため取り込みはしていますが、Cloud SIEMでの分析対象にするのはやめました。

理由としては、AWS WAFに関しての標準の検出ルールでは以下の4つのうち 3. と 4. はCroudTrailのログから検出されるルールのためWAFのログは不要なのと、1. と 2. はダッシュボードで確認できる内容であったこと、そしてWAFのログは記載される情報の内容からアクセスログなどと比較しても容量がとても大きいためCloud SIEMの分析対象に含めるとコストがかなり増えることから、Cloud SIEMの分析対象から除外しました。

  1. AWS WAF traffic blocked by specific rule
  2. AWS WAF traffic blocked by specific rule on multiple IPs
  3. AWS WAF web access control list deleted
  4. AWS WAF web access control list modified

③セキュリティシグナルでの検出内容の確認

Cloud SIEMを有効にして、必要なログをDatadogへ取り込みできれば、Cloud SIEMがログの情報からリアルタイムで検出ルールに該当した脅威を検出してくれます。
検出した内容はCloud SIEM画面の「Signals」タブから確認ができます。

Cloud SIEM - Signals
Cloud SIEMのSignals画面

脅威が検出されると、セキュリティシグナルが生成されて、重大度や発生時期、シグナルをトリガーするすべてのログの情報を関連づけて要約してくれます。
どのようなイベントが該当のルールに引っかかたのかなどをセキュリティシグナルエクスプローラーの画面上で紐づけされて詳細が見れたり、該当の検出ルールに該当したログの情報にも画面上で遷移しているため、トラブルシューティングや原因調査がとてもしやすくなります。
また、Cloud SIEM ではLogsのログ保存期間の設定日数に関係なく、 15 か月間にわたってこのセキュリティシグナルは保存されます。

セキュリティシグナルの検出画面
セキュリティシグナルで検出された詳細画面

このセキュリティシグナルエクスプローラーの詳細については以下を参考にしてください。

https://docs.datadoghq.com/ja/security/explorer/

Cloud SIEMの料金について

Cloud SIEMで分析をする対象のログはデフォルトでは、 Datadogで取り込んだすべてのログが分析対象になります 。そしてCloud SIEMの料金設定は分析されたログの容量により料金が決定します。
https://www.datadoghq.com/ja/pricing/?product=cloud-siem#products

Cloud SIEMのセキュリティシグナルエクスプローラーで検出されているものは、分析対象となっているログの内容から、Datadogで用意された検出ルール（OOTB Rules）の「LOG DETECTION」や、利用者側で作成したカスタムのログ検出ルールに当てはまるものを脅威として検出しています。

しかし、Dashboards機能などでの利用でLogsに取り込んでいた独自開発のアプリケーションログなどにおいては、Cloud SIEMではそのログも分析対象として読み込みはするものの、LogsのPipelinesで他のログなどと相関的に分析できるように属性などをパースしない限りは、ルールで検出されることはほぼないと思われるのですが、Cloud SIEMで分析されたログとして課金がされてしまいます。

実際にDatadogで用意されている検出ルールの設定内容をいくつか確認してみると、「Define search」で「Source」で指定されているログソースなどから脅威をチェックしています。
Detection Rules > New Amazon EC2 Instance type
検出ルールの設定内容の一例

  • Datadogで用意されている検出ルールの設定内容はCloud SIEM 画面の上部タブメニューの「Detection Rules」から確認できます

すべての検出ルールをチェックしたわけではないので、かならずしもすべての検出ルールが「Source」で特定のログを指定しているわけではないかもしれませんが、OOTB Rulesの「CLOUD SIEM　(LOG　DETECTION)」でAWSに関連するルール名などを見る限りでは、おそらく多くはCloudTrailやGuardDutyのログから検出されるものが主であるように考えられ、それ以外のログでは利用者自身でCloud　SIEMでの検出ルールの条件にあわせてパースなどしない限りは、それぞれのルールで脅威の検出で使用されることはないのではと予想しています[1]。

前段でも書いた通りCloud SIEMでの課金対象はDatadogで取り込んだすべてのログが分析対象であり課金対象となるため、脅威としての検出で使用されることがないであろうログも課金対象となるのは、無駄なコストがかかっているということにもなります。

ついてはCloud SIEMで脅威の検出に必要なログをセキュリティフィルタで絞って無駄なコストを減らしてみました。

①Cloud SIEMで脅威の検出に必要なログを精査

Cloud SIEMで標準で検出の対象となるログに関してははっきり明言されていませんが、おそらくはメニュー「Security > Configuration」にあるCloud SIEMの「Log Sources」にあるソースのログではないかと想定しています。
Log Sources画面
Security > Configuration の「Log Sources」画面
Datadogが用意している推定使用量メトリクスで以下のメトリクスで比較してみると、Cloud SIEMの課金対象となっているログ量はDatadogのログ取り込み量と同じですが、 分析ログ (セキュリティ)でソース別で計算するとCloud SIEMでの検出ルールでのログソースの対象[2]になっているのは少ないように見えます。

使用タイプ メトリクス 説明
ログ取り込みバイト datadog.estimated_usage.logs.ingested_bytes バイト単位のログの取り込みの合計
分析ログ (セキュリティ) datadog.estimated_usage.security_monitoring.analyzed_bytes バイト単位の Cloud SIEM ログの取り込みの合計
分析ログ (セキュリティ)/ソース別 datadog.estimated_usage.security_monitoring.sources.analyzed_bytes バイト単位の Cloud SIEM のソース別ログの取り込みの合計
  • 「ログ取り込みバイト」のメトリクスによるグラフでは月合計4.16TB
    ログ取り込みバイトのメトリクスによるグラフ
    Logsのログ取り込み量のメトリクスによる月合計は4.16TB
  • 「分析ログ (セキュリティ)」のメトリクスによるグラフでは月合計4.16TBで「ログ取り込みバイト」と同じ （Cloud SIEMの課金対象のグラフ）
    分析ログ (セキュリティ) のメトリクスによるグラフ
    Cloud SIEMの分析ログのメトリクスによる月合計4.16TB
  • 「分析ログ (セキュリティ)/ソース別」のメトリクスによるグラフではCloudTrailが合計760.36GB、ELBが合計555.97GB、GuardDutyとRoute53は数MBほどで月合計は1.32TBで分析ログ (セキュリティ)よりも少ない
    分析ログ (セキュリティ)/ソース別のメトリクスによるグラフ
    Cloud SIEMの分析ログ(ソース別）のメトリクスによる月合計1.32TB

ライフイズテックの場合は、前段にも記載しました以下の4つのログのみをCloud SIEMでの検出対象とすれば現状検出したい脅威に対しては影響はほぼないと判断し、この４つのログソースのみを対象とするようにCloud SIEM API によるセキュリティフィルターを設定しました。

②Cloud SIEM API によるセキュリティフィルター設定

Cloud SIEMですべてのログではなく、特定のログのみを分析対象とするにはCloud SIEM APIによるセキュリティフィルターで設定する必要があります。
セキュリティフィルターの設定はDatadogのWEB画面からではなく、Cloud SIEM APIに対して cURL などでコマンドラインでリクエストを送る形式で設定を行います。

https://docs.datadoghq.com/ja/security/cloud_siem/guide/how-to-setup-security-filters-using-cloud-siem-api/

セキュリティフィルターは、Cloud SIEM 製品によって分析されたログを制御するためにのみ必要です。
Cloud Security Management Threats (source:runtime-security-agent) および Cloud Security Management Misconfigurations (source:compliance-agent) 製品の一部として Datadog Agent によって生成されたログを除外するために、セキュリティフィルターを作成する必要はありません。
分析ログとして請求されないためです。

以下はCloud SIEM APIによるセキュリティフィルター設定の手順です。

1.　DatadogのAPIキーとアプリケーションキーを用意する
2.　現在のフィルターの設定を確認する (curlコマンドによるAPI callでの設定）
3.　カスタムフィルターを追加作成する (curlコマンドによるAPI callでの設定）
4.　デフォルトのセキュリティフィルターを無効化する (curlコマンドによるAPI callでの設定）

1.DatadogのAPIキーとアプリケーションキーを用意する

Cloud SIEM APIを利用するには、DatadogのAPIキーとアプリケーションキーが必要です。

アプリケーションキーの作成または編集の権限を持つユーザーまたはサービスアカウントは、アプリケーションキーのスコープを行うことができます。ユーザーは自分のアプリケーションキーをスコープするためには user_app_keys 権限、または自分の組織内の任意のユーザーが所有するアプリケーションキーをスコープするためには org_app_keys_write 権限が必要です。サービスアカウントのアプリケーションキーをスコープするには、service_account_write 権限が必要です。
（APIキーとアプリケーションキー より抜粋）

APIキーとアプリケーションキーの作成には、Datadog上でアプリケーションキーの作成または編集の権限を持つユーザーでないと作成ができませんので、権限があるかについてはDatadogの管理者に確認してください。

  • 権限がない、または権限を付与してもらえない場合は、Datadogの管理者にAPIキーとアプリケーションキーを用意してもらうか、Datadogの管理者側でCloud SIEM API によるセキュリティフィルター設定を依頼してください。

以下はDatadogの「Organization Settings」画面でAPIキーやアプリケーションキーを発行する手順です。
生成されたAPIキーとアプリケーションキーは後ほどCloud SIEM APIへのAPI callの実行の際に使用しますので忘れないようにしてください（取り扱いにも注意してください）。

<APIキーの作成>

  1. DatadogのWeb画面の左下のアカウント名をクリックして表示したメニューから「Organization Settings」を選択
    menu - Organization Settings
    Organization Settingsへのメニューの場所
  2. 「Organization Settings」のメニューから「ACCESS」の「API keys」を選択
  3. 左上にある「＋ New Key」ボタンをクリック
  4. 「New Key」画面でAPIキーの名前を入力して「Creat Key」ボタンを押す
    APIキーの名称記入
    APIキーの名称を記入して「Creat Key」ボタンを押す
  5. 「New Key」画面で表示している鍵アイコンのあるKey情報の「Copy」ボタンを押してKey情報をコピーし、メモ帳などにペーストしてAPIキーとして控えておいてください。
    Key情報
    Keyの「Copy」ボタンを押して生成されたAPIキーを控えておく

<アプリケーションキーの作成>

  1. DatadogのWeb画面の左下のアカウント名をクリックして表示したメニューから「Organization Settings」を選択
    menu - Organization Settings
    Organization Settingsへのメニューの場所
  2. 「Organization Settings」のメニューから「ACCESS」の「Application Keys」を選択
  3. 左上にある「＋ New Key」ボタンをクリック
  4. 「New Key」画面でアプリケーションキーの名前を入力して「Creat Key」ボタンを押す
    アプリケーションキーの名称記入
    アプリケーションキーの名称を記入して「Creat Key」ボタンを押す
  5. 「New Key」画面で表示している「Scope」の「Edit」ボタンを押す
    ScopeのEdit
    「Scope」ボタンを押す
    ６. 「Edit Key Scope」画面から「Cloud Security Platform」にある「security_monitoring_filters_read」と「security_monitoring_filters_write」を選択して「Save」ボタンを押す
    Edit Key Scope
    アプリケーションキーで許可する権限のScopeを選択する
  6. 「New Key」画面で表示している鍵アイコンのあるKey情報の「Copy」ボタンを押してKey情報をコピーし、メモ帳などにペーストしてアプリケーションキーとして控えておいてください。
    Key情報
    Keyの「Copy」ボタンを押して生成されたAPIキーを控えておく

2.　現在のフィルターの設定を確認する (curlコマンドによるAPI callでの設定）

セキュリティフィルターは初期の状態ではデフォルトで取り込んだすべてのログを分析する単一のセキュリティフィルターが存在しています。
そのデフォルトのセキュリティフィルターの名前は「all ingested logs」で、すべてのログを分析対象として設定がされています。

現在設定されているセキュリティフィルターは以下のcURLによるAPI callで確認ができます。

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>'

API callのレスポンスとして以下のような内容が返ってきます。

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情報が設定され、後述のフィルターの設定変更をする場合はこのフィルターIDを指定して変更を行うので控えておいてください。

3.　カスタムフィルターを追加作成する (curlコマンドによるAPI callでの設定）

Cloud SIEMでの分析を明示的に指定されたログのみに制限するため、カスタムセキュリティフィルターを追加で作成します。

前述で説明したとおり、今回の例では以下の４つのログソースのみをCloud SIEMでの分析対象とするようにCloud SIEM API によるセキュリティフィルターを設定します。

  • CloudTrail
  • Route53
  • ELB
  • GuardDuty

以下のAPI callで「--data-raw」にてJSON形式のフィルター設定内容を指定します。
フィルターの名称例として「cloudtrail elb guardduty route53」とし、クエリを「source:(cloudtrail OR elb OR guardduty OR route53)」と指定しました。

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)"
        }
    }
}'

設定されると以下のレスポンスが返ってきます。
デフォルトのセキュリティフィルター「all ingested logs」に、カスタムのセキュリティフィルター「cloudtrail elb guardduty route53」が追加され、2つのセキュリティフィルターが存在していることが確認できます。

Response
{
    "data":[
        {
            "id":"l6l-rmx-mqx",
            "attributes":{
                "version":1,
                "name":"all ingested logs",
                "query":"*",
                "is_enabled":true,
                "exclusion_filters":[],
                "filtered_data_type":"logs",
                "is_builtin":true
            },
            "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"
        }
    ]
}

デフォルトのセキュリティフィルターとカスタムのセキュリティフィルターは、両方とも data.is_enabled の値は「true」になっているので両方とも有効な状態となっております。
セキュリティフィルターは包括的なため、複数のセキュリティフィルターが設定されていても、特定のログが少なくとも 1 つのセキュリティフィルターに一致する場合は分析されます。
この状態だとすべてのログがデフォルトのセキュリティフィルターと一致してしまい、すべてのログが分析対象となるため、デフォルトのセキュリティフィルターを無効化する必要があります。

4.　デフォルトのセキュリティフィルターを無効化する (curlコマンドによるAPI callでの設定）

前述でも記載した通り、セキュリティフィルターは包括的のため、複数のセキュリティフィルターがある場合は、特定のログが少なくとも 1 つのセキュリティフィルターに一致する場合に分析されます。
デフォルトのセキュリティフィルター「all ingested logs」のクエリは「*(ワイルドカード)」のため全てのログを対象としており、このままでは追加したカスタムのセキュリティフィルターでの制限がかからないので、 デフォルトのセキュリティフィルター「all ingested logs」をAPI callで無効にします

特定のセキュリティフィルターを無効化する場合は、api.datadoghq.comのURIで該当のセキュリティフィルターIDを指定する必要があります。
今回、デフォルトのセキュリティフィルター「all ingested logs」のフィルターID「l6l-rmx-mqx」を指定しているところに注意してください。
そして、無効化を指定するため「is_enabled」の値を「false」 で指定します。

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"
    }
}'

レスポンスを確認するとフィルターID「l6l-rmx-mqx」の「is_enabled」が「false」 になったことが確認できます。
これによりセキュリティフィルターが有効になっているものがフィルターID「qw3-spe-wsx」のカスタムフィルターのみになり、このフィルターで設定されているDatadog　Logsの「source」が「cloudtrail」、「elb」、「guardduty」、「route53」のいずれかに該当するログのみCloud SIEMでの分析対象となります。

Response
{
    "data":[
        {
            "id":"l6l-rmx-mqx",
            "attributes":{
                "version":2,
                "name":"all ingested logs",
                "query":"*",
                "is_enabled":false,
                "exclusion_filters":[],
                "filtered_data_type":"logs",
                "is_builtin":true
            },
            "type":"security_filters"
        },
        {
            "id":"qw3-spe-wsx",
            "attributes":{
                "version":2,
                "name":"cloudtrail elb guardduty",
                "query":"source:(cloudtrail OR elb OR guardduty OR route53)",
                "is_enabled":true,
                "exclusion_filters":[],
                "filtered_data_type":"logs",
                "is_builtin":false
            },
            "type":"security_filters"
        }
    ]
}

設定してしばらく経つと・・・

Cloud SIEMのログ分析量はDatadogのWeb画面の左下のアカウント名をクリックして表示したメニューの「Plan & Usage」から確認ができます。

Plan & Usage
Plan & Usageへのメニューの場所

「Plan & Usage」の「Usage」タブを開くとDatadogの各機能毎の料金のグラフが表示されます。
「Plan & Usage」の「Usage」画面
「Plan & Usage」の「Usage」画面

画面を下にスクロールすると「Usage Summary」の箇所で利用したDatadogの機能毎の「Total Usage」の数字や「Usage Trends」のグラフを確認することができます。
以下の「Security」タブ画面の「Security Usage Trends」のグラフを見ていただくと、8月15日から「Analyzed Logs (Security)」の棒グラフの量が少なくなっていますが、まさしくCloud SIEM API によるセキュリティフィルター設定をした日であり、それ以降は分析ログ量が減ったことがわかります。
（8/28以降に分析量が増えているのはサービスへのアクセスが増えてきたとこによる影響です）
Usage Summary - Security
Usage Summary - Securityの画面

さいごに

今回、DatadogでもCloud SIEMを有効にして監査ログなどの分析を開始する手順と、Cloud SIEMで分析する対象のログをセキュリティフィルターで設定して脅威の検出に必要なログの分析を除外することでCloud SIEMのコストを削減する方法を紹介しました。
Datadogは利用しているけどCloud SIEMの利用を検討されている方の利用の助けになったらうれしいです。

なお、ライフイズテック サービス開発部では、今後定期的なカジュアルなイベントを実施していく予定です。
開催予定イベントの詳細はライフイズテックのconnpassからご確認ください。
https://life-is-tech.connpass.com/

脚注

  1. あくまで個人的な見解です。 ↩︎

  2. 分析ログ (セキュリティ)/ソース別のメトリクス「datadog.estimated_usage.security_monitoring.sources.analyzed_bytes」の説明がマニュアルから見当たらないので、実際の意味合いは違うかもしれません。 ↩︎

Discussion