Datadog Cloud SIEMを利用してみた＆ちょっとしくじった話

ぎだじゅん

2023年9月29日 17:52

新しいiPhoneを買って浮かれている「ぎだじゅん」です。
ライフイズテックという会社でサービス開発部インフラ/SREグループに所属しています。

長い間iPhone SEを使ってきましたが、今回、私もiPhone15 Pro Maxを購入しました！！
カメラレンズがボトムズみたいなやつで、画面が大きいタイプ！！

2年前のiPhone13が発表されたときに翌年のiPhone14でUSBがType-Cになったら買おうとiPhone貯金してきたけど肩透かしを食らい、結局2年でPro Maxに手を出せるまで貯金できたので、勢いで買ってしまいました！！！

これまでiPhone SEを使っていて、不満だったのは以下の通り。

バッテリーが1日持たないことが多い
画面の表示サイズが狭い
スマホカメラでズームができる憧れ
家のUSB充電をType-Cに統一したい
（周りに自慢され続けてきたので）自分もスマホ自慢したい

もう、買い替える条件は十分にそろっているし、どうせ買うなら今の時点で一番いいスペックを買った方が長く使える（だろう）し、大きいことはいいことだと（自分の体型的に）自負しているので、こうなったら機種はPro Max一択です。

そして9/22に製品が届いて1週間・・・

これまでのiPhone SEと比較して、いきなりMaxサイズになってとにかく重くてデカい。
持って移動すると、これまでと違う重量に違和感を感じる。
大きいということはそういうことだと（自分の体型的に）自分がよくわかっていたはず・・・。

ちょうど同じタイミングで同僚がiPhone15 Proを持っていたので触らせてもらったら、SEよりはちょっと重いけど超ジャストサイズ！
バッテリー容量もiPhone SE(2nd)が1,821mAhに対してiPhone15 Proでも3,274mAhと十分増えているし、冷静に考えたらカメラの利用頻度が居酒屋めしやラーメンしか撮らないのに5倍ズームはオーバースペック、iPhone15 Proの3倍ズームで十分。
機能的にはPro Maxのほうがいいのに、iPhone15 Proの快適さを目のあたりにして、なんだか結局自慢された気分・・・(´；ω；`)ｳｩｩ

今の時点で一番いいスペックを選択することが正義だと思っていましたが、自分の身の丈にあった機種選定の見積もりを誤った気がします。

本題です。

前回のおさらい

前回はSIEMのダッシュボードをDatadogへ移行した話をしました。

DatadogでAWS環境の各種ログを収集して、ログの情報からセキュリティのインシデントの予兆を可視化できるようにダッシュボードを作成し、現在も日々このダッシュボードを使って異常がないかなどを確認しています。

また、DatadogではAWS環境などで起きるインシデントの予兆や不審なリソースの追加や修正などを監査ログからリアルタイムで検出してくれる Cloud SIEM というサービスがあり、これを使うことで異常があるかもの判断をあらかじめ用意されたルールで自動で検出して通知や可視化（ダッシュボード表示）してくれます。

今回はこの Cloud SIEM の簡単な概要の説明と、導入時にちょっとしくじってしまい最初にコストがかかってしまったこととその改善策についてドキュメントでお話します。

Cloud SIEMについて

Datadog Cloud SIEM は、アプリケーションやインフラストラクチャーに対する脅威をリアルタイムに検出します。
これらの脅威には、標的型攻撃、脅威情報が記載された IP がシステムと通信している場合、または安全でない構成が含まれる場合があります。検出されるとシグナルが生成され、チームに通知することができます。

Datadog「Cloud SIEMの概要」より

Datadog Cloud SIEM ではDatadog側へ収集したログから Datadog が用意している検出ルール（ OOTB Rules ）にて脅威を検出してくれます。
以下はAWSの監査ログ（CloudTrail）やELBのアクセスログなどから検出されるデフォルトで用意されたルールの一部です。
例はAWS環境ですが、このほかにもAzureやGCPなどのクラウド環境でも同じようなルールがデフォルトで用意されています。

各種リソースの変更
- S3バケットポリシー変更
- IAMポリシー変更
- RDS削除
- セキュリティグループの作成/変更/削除、インバウンドルールでの全公開、データベースポートのパブリック公開
- S3パブリックアクセスブロックの削除
- SecurityHub/Config/CloudTrailの無効化
- WAFのWebACL変更/削除
- VPCの各種変更（VPCの作成、ルートテーブルやネットワークゲートウェイの作成/変更、サブネットの削除など）
- CloudWatchロググループの削除やルールの無効化/削除
- KMSキーの削除（削除スケジュールの設定）
- EventBridgeのルール変更や削除
異常な数のアクティビティ
侵害の疑い
AWS ConsoleLogin
不用意な公開/流出や漏洩の疑い
その他
- Log4Shell スキャンの検出
- セキュリティスキャナからのHTTPリクエスト

以下のようなダッシュボードでルールに引っかかったものを集計表示させています。

これらのルールに該当する脅威が検出されると、セキュリティシグナルが生成されて、重大度や発生時期、シグナルをトリガーするすべてのログの情報を関連づけて要約してくれます。

どのようなイベントが該当のルールに引っかかたのかなどを画面上で紐づけて見れるため、トラブルシューティングや原因調査がとてもしやすくなります。
また、シグナルが発生した際にSlackやメール、Webhookでアラートを通知することもできます。

さらにDatadogのログに関しては、設定したログの保持期間（弊社では7日間）を経過するとインデックスから削除されてダッシュボードやLogsのAnalyticsからは検索できなくなりますが、Cloud SIEM では検出したセキュリティシグナルの情報に関しては 15 か月間保存されます。

SIEMを使った運用やインシデントの検出について初めてでどのようなルールでインシデントの予兆や異常を判別して検出すればよいかわからない方にも、デフォルトのルールでスタートができるし、利用者での監査対象のクラウド環境の利用実態や状況にあわせてルールを少しづつカスタマイズすることで、ゼロからルールを作成するよりも簡単に自社に適したルール運用にフィットさせていくことができます。

でもお高いんでしょ？

Cloud SIEMの利用にあたって必要な料金には以下があります。

Cloud SIEM

分析されたログ 1 GB あたり$0.25/月

https://www.datadoghq.com/ja/pricing/?product=cloud-siem#products より

ログ管理

＜取り込み＞
取り込みまたはスキャンされたログ 1GBあたり $0.13

＜保持または復元＞
100 万ログイベントあたり $1.59/月（7日分保持するの場合）
100 万ログイベントあたり $1.59/月（30日分保持する場合）

https://www.datadoghq.com/ja/pricing/?product=log-management#products より

Cloud SIEMはログがないと分析できないので、Cloud SIEMを利用するにはCloud SIEMの料金と、ログ管理の料金の両方が必要となります。

すでにAWS環境のモニタリングでログを取り込んでいるDatadogでCloud SIEMを利用する場合、すでに取り込んでいるログにSIEMの分析で必要なログ（AWSであればCloudTrailログなど）なども含まれていれば、追加の費用はCloud SIEMのみの想定。
Cloud SIEMの利用にあたり、セキュリティインシデントを検出するために新たに取り込むログを追加する場合は、追加分のログにてログ管理の料金が加算されます。

今回の導入にあたっては、すでにシステムモニタリングで利用中のDatadogにCloud SIEMの機能を追加導入する際に、Cloud SIEMで分析されるログの容量からおおよそ月間でどれくらいの料金追加になるかを試算しました。

試算してみました

Cloud SIEMの料金とログ管理の取り込みの料金については、実際に取り込むログの容量から試算できそうなので、まずはDatadogへ追加で取り込むログの容量から算出して計算してみました。

Cloud SIEMで分析される対象のログですが、以下を想定しています。

CloudTrailの証跡ログ
ALB（Application Load Balancer）のアクセスログ
GuardDutyの検出結果ログ

ALB（Application Load Balancer）のアクセスログに関しては、すでにシステムのモニタリングでDatadogで取り込んでいるので、Datadogのサービス別ログ取り込みバイト数のメトリクスからサービス「elb」の容量でおおよそ700GB/月と算出。
ログ管理ではすでに課金されているので、今回の追加分の見積ではCloud SIEMのみ料金を試算しています。

GuardDutyは異常検出時にログ出力されますが、1検出あたり1.2～1.4KB程度なのと、これまででGuardDutyで検出されるケースは少なく微々たる量なので試算には含みませんでした。

今回初めて取り込むCloudTrailの証跡ログについては、AWS側でログ出力先となっているS3バケットからアクセスピークとなる月のPrefixでログ容量を算出しました。
S3バケットの容量はAWSコンソールで「合計サイズを計算する」で確認できます。
算出したところ、以下のような結果でした。

CloudTrailの証跡ログ：59.7GB/月

ということで、これで試算すれば・・・、いや、ちょっと待った！！

ログの取り込みの容量は非圧縮データの容量で試算する必要があるので、CloudTrailのいくつかのログをダウンロードして解凍し、圧縮率（圧縮時の容量÷解凍後の容量）を算出してみたところ、元容量の内容や容量によって違いはありましたが、おおよそ6～15%ぐらいでした。
ついては今回、間をとって圧縮率10%で計算すると 59.7GB÷10%=597GB なので、CloudTrailのログの取り込み量は 597GB/月 と試算。

ここに記載した圧縮率は、あくまで弊社で算出した参考値で正確な容量の試算を保証するものではございません。ご了承ください。

ALB（Application Load Balancer）のアクセスログは 700GB/月 、CloudTrailの証跡ログは 597GB/月 で計算すると、今回のCloud SIEM導入によるDatadog料金の追加分は、合計で $521.96/月の追加と予想しました。

Cloud SIEM
　ALBのログ：700GB × $0.25 = $175/月
　CloudTrailのログ：597GB × $0.25 = $149.25/月

ログ管理
＜取り込み＞
　ALBのログ：（ずでに取り込み済みなので追加なし）
　CloudTrailのログ：597GB × $0.13 = $77.61/月

＜保持または復元（7日分保持するの場合）＞
　ALBのログ：（ずでに取り込み済みなので追加なし）
　CloudTrail：76,100,000ログイベント÷1,000,000×$1.59 = $121/月

＜保持または復元＞のイベント数については、S3バケットに出力されているCloudTrail証跡ログのオブジェクト数を7日分、AWSコンソールの「合計サイズを計算する」で確認して試算しました（それが正しいかわかりませんが）。

Cloud SIEM追加により月のコストがこれだけ追加になりますと上長に報告して承認をもらい、いざCloud SIEMの利用を開始しました。

見積もりが甘かった・・・？

Cloud SIEM導入によりインシデントの予兆や異常、リソースの変更状況などを検出してくれ、順調にSIEMによる運用をまわして1か月後。
そういえばCloud SIEMの料金がどれくらいになるだろうとDatadogのPlan & Usageを見てみると・・・

Cloud SIEMで試算していた容量は ALBのログ：700GB と CloudTrailのログ：597GB であわせて 1,297GB（1.23TB）ぐらいの想定のはず・・・

それから差し引いた3TBのログはどこから・・・
それともログの圧縮率を誤って見積もってしまったのか・・・
iPhoneの機種選定の見積もりも甘い自分なのでありえるのかも・・・

予想しなかった約3TB分のログ分析

Cloud SIEMで検出されている情報が参照しているログを確認していくと、分析で使われているログのほとんどは、以下のログのみに見えました。

CloudTrailの証跡ログ
ALB（Application Load Balancer）のアクセスログ
GuardDutyの検出結果ログ

検出ルール（ OOTB Rules ）の「CLOUD SIEM (LOG DETECTION)」でも、AWS環境関連で検出するルールは「CloudTrail」や「ELB」、「Guard Duty」が主なように見えます。
弊社ではこれら以外にシステムモニタリングの用途でサーバアプリケーションで出力されるログやWAFでの検出ログなどをDatadogへ取り込んでいますが、これらのログは現状ではSIEMで分析されるようなパースやマッピングはされていない（Datadogのパイプラインでパースされていない）のでCloud SIEMでの分析はされない想定でした。
（後述でこの想定が誤っていたことに気づきます）

しかし、Datadogの料金に関係するメトリクスを確認してみると、ログ管理での容量とCloud SIEMでの分析容量が同じ状態で遷移していて、いずれも月末の累計グラフ（紫の線グラフ）で最終的に4.16TBと同じ容量になっています。

ログ管理（ログの取り込み）7月分
[datadog.estimated_usage.logs.ingested_bytes]

Cloud SIEM（分析ログ）7月分
[datadog.estimated_usage.security_monitoring.analyzed_bytes]

また、Cloud SIEMで分析したソース別のログを確認できるメトリクスがあったので、見てみたら・・・

Cloud SIEM（ログソース別）7月分
[datadog.estimated_usage.security_monitoring.sources.analyzed_bytes]

黄色いグラフがALB（Application Load Balancer）の累計で760.36GB、紫色のグラフがCloudTrailの累計で555.97GB、それ以外のログソースは1MBもない模様で、やはり導入前に試算したCloud SIEMの見積とそれほど大きな差がない内容でした。

やっぱり、CloudTrailやALB（Application Load Balancer）以外のログも分析対象として課金されちゃってるのでは！？と思い、Datadogに問い合わせたところ原因がわかりました。

取り込まれるすべてのログが課金対象

Cloud SIEMで分析をする対象のログは、デフォルトではDatadogへ取り込んだすべてのログがCloud SIEMでの分析対象になるようです。
検出ルール（ OOTB Rules ）にて検出される/されないは料金には関係なく、ログ管理で取り込まれるすべてのログをCloud SIEMで一度チェック（分析）しているので、ログ管理の取り込み容量＝Cloud SIEMの分析容量 となり、取り込まれたすべてのログがCloud SIEMの分析での課金対象となっていました。

うぅ～～ん、言っていることはよくわかるのですが、いくつかのログはパースやマッピングしたりカスタマイズルール作らないと現状ではCloud SIEMのルールで検出されることはほぼないだろうし、可能であればサーバアプリケーションなどのログはCloud SIEMの分析対象から除外したいと思っていたら、除外する方法がありました。

セキュリティフィルターで分析対象のログをフィルタする

Cloud SIEMで特定のログのみを分析対象とするには Cloud SIEM APIによるセキュリティフィルター で分析対象としたいソースのログのみにフィルタすることができます。

Datadog は、Datadog Cloud SIEM サービスによって取り込まれ分析されたギガバイトの総数に基づいて、分析されたログの料金を請求します。デフォルトでは、Cloud SIEM は、取り込んだすべてのログを分析して、検出範囲を最大化します。ただし、Cloud SIEM API を使用すると、プログラムでセキュリティフィルターを設定して、取り込んだログのどのサブセットを分析するかを構成できます。

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

セキュリティフィルターはDatadogのWEB画面からではなく、Cloud SIEM APIに対して cURL などでコマンドラインでリクエストを送る形式で設定を行います。
このセキュリティフィルターの設定方法については、こちらの私の投稿で紹介していますので、よかったらご覧ください。

弊社では、今回以下のような内容でフィルタ設定しました。

{
    "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"
        }
    ]
}

2種類のフィルタ設定がありますが、「"id":"l6l-rmx-mqx" 」のフィルタはデフォルトのフィルタでDatadogのLogsで読み込まれたすべてのログ（"query":"*"）を分析対象としていますが、このデフォルトのフィルタを無効化（"is_enabled":false）しています。
そして今回追加した「"id":"qw3-spe-wsx"」のフィルタでは、DatadogのLogsで読み込まれたログのうち、DatadogのLogsでのSourceが「cloudTrail」と「elb」と「guardduty」と「route53」のみ（"query":"source:(cloudtrail OR elb OR guardduty OR route53)"）を分析対象とするように設定しました。
これで、特定のログのみをCloud SIEMでの分析対象とすることができました。

セキュリティフィルタの設定をしてから1か月後のログ取り込みと分析の容量の状況を確認してみました。

半日単位の棒グラフの増減が前述での7月分のグラフと比較するとかなり容量が違いますが、これは今回は夏休み期間中で弊社のサービス利用が少ない時期である影響ですので気にしないでください。

ログ管理（ログの取り込み）8月分
[datadog.estimated_usage.logs.ingested_bytes]

Cloud SIEM（分析ログ）8月分
[datadog.estimated_usage.security_monitoring.analyzed_bytes]

今回、累計（紫の線グラフ）の最終日の値が、ログ管理（ログの取り込み）は3.77TBなのに対して、Cloud SIEM（分析ログ）ではセキュリティフィルタを設定した8月15日から半日あたりの分析ログの容量が減り、最終的に累計で1.8TBと減らすことができました。

フィルタしたことで、Cloud SIEMで検出されなくなったものも増えてるのではという懸念に関しては、明確にはわかりませんが、前月のセキュリティフィルタ前の検出結果などと比較しても差異はなさそうな印象でした。

セキュリティフィルタでフィルタする内容は、あくまで自己責任でお願いします。
（Datadogさん側で新しいデフォルトルールなどが増えたけど、フィルタしたことで対象ログが分析対象から外されて異常検出されなかったなどもあるかもしれませんので）

ちょっと高額な勉強代にはなりましたが、ゲームで隠しコマンドを見つけて攻略して次の面へ進めた感じがします。

最後に

なんだか今回の内容もDatadog社の回し者みたいな内容になってしまいましたが、同じようなことで困った方に届いたらいいなと思い投稿してみました。
iPhoneの機種選定の見積もりが甘くても、Datadogの容量の見積もりは間違っていなかった（けど落とし穴に落ちた）お話でした。

こんな失敗してもチャレンジを大事にしてくれる今の会社はとてもいい会社なので、興味のある方はこちらも是非見てみてください。

この記事が気に入ったらサポートをしてみませんか？