[連載]全体の可視化と分析。ログを集めても、判断に変わらなければ意味がない。材料は調理しないと料理にはならない。[第6回]
恐縮です。
ここらはもはや運用の話に近いです。運用設計ってあんまりやらないんですよね。会社の文化もあるし、ヘルプデスク丸投げの会社さんもあるし。
操作引継ぎだけで終わることもあるし。
ゼロトラストの話も、第6回まで来ました。
アイデンティティを整える。
デバイスを見る。
ネットワークの到達経路を引き直す。
ワークロードを可視化する。
データを守る対象として定義する。
ここまで来ると、かなり重要な問いにぶつかります。
それで、何が起きているのか見えているのか。
仕事でよく言われます。「で、どうしたいの？」「だからなに？」
ここです。
ゼロトラストは、制御を細かくする話です。
でも、細かく制御するには、細かく見えていなければいけません。
誰がアクセスしたのか。
どの端末から来たのか。
どのアプリに到達したのか。
どのデータに触ったのか。
何がいつもと違うのか。
どのイベントを本当に危ないと見るべきなのか。
これが見えていないと、ゼロトラストはかなり弱くなります。
ポリシーはある。
製品もある。
ログもある。
でも、判断できない。
これが一番もったいないです。
だから先に言い切ります。
可視化と分析の柱は、ログを集める柱ではありません。
各柱から出る信号を、判断と対応に変える柱です。
ここを間違えると、SIEMはただのログ倉庫になります。
ダッシュボードはきれい。でも誰も見ない。
アラートは多い。でも優先順位が分からない。
調査はできる。でも初動が遅い。
この状態はかなり危ないです。
ゼロトラストにおける可視化と分析は、見える化で終わりません。
見える。
つなげる。
意味づける。
優先順位をつける。
対応へ渡す。
ここまでやって、初めて柱になります。
参考URL
この柱は、まだ後回しにされやすい
ここは少し現実を見た方がいいです。
可視化と分析は大事です。
でも、導入と運用はまだ十分に進んでいるとは言いにくい。
国内のゼロトラストの取り組みを見ると、先に進みやすいのはアイデンティティやネットワークです。(感覚ですが)
IDaaS、EDR、SSE/SASE。
このあたりは、比較的話が進みやすい。
見た目の変化も出ます。
導入した感も出ます。
一方で、可視化と分析は後回しになりやすい。
理由は単純です。
入れれば終わりではないからです。
ログを集めるだけなら始められます。
でも、そこから検知ユースケースを作る。
アラートをチューニングする。
誰が見るかを決める。
一次対応を回す。
誤検知を減らす。
現場部門とつなぐ。
ここまでやらないと価値が出ません。
これはかなり重いです。
だから進みにくい。
でも、ここをやらないとゼロトラストは最後に止まります。
制御の材料は増えたのに、それを判断に変えられないからです。
Gartner Japanは、国内ではIAMやSASE関連の取り組みが優先的に進んできた一方で、XDR/SOARは多くの企業で議論が進んでいないと指摘しています。
IIJの国内調査でも、ゼロトラストの必要性を感じる企業は多い一方、セッション単位の検証・認可や動的なアクセス制御はまだ課題として残っています。
つまり、ゼロトラストは「導入済み」ではなく、まだかなりの部分が「部分導入」なんです。
ここを見誤ると危ない。
可視化と分析は、最後に余裕があればやるものではありません。
むしろ、各柱を本当に効かせるための接着剤です。
参考URL
https://www.gartner.co.jp/ja/newsroom/press-releases/pr-20240422
https://www.iij.ad.jp/news/pressrelease/2024/pdf/zerotrust_research.pdf
NSAは、この柱をどう見ているか
この第6回で押さえておきたいのが、NSAの「Visibility and Analytics」ガイダンスです。
NSAは2024年に、ゼロトラストの可視化と分析の柱について、Cybersecurity Information Sheetを公開しています。
この文書でNSAが言っていることは、かなり実務的です。
可視化と分析は、ただログを集める話ではありません。
企業環境全体で発生するデータの特徴やイベントを観測し、ポリシー判断、対応アクション、リスクプロファイル作成に使うものとして整理されています。
ここが重要です。
NSAはこの柱を、ゼロトラスト戦略の中核に近い位置で見ています。
なぜか。
他の柱から出るログや信号を集めて、全体像を作るからです。
アイデンティティのログだけでは足りない。
端末ログだけでも足りない。
ネットワークログだけでも足りない。
データログだけでも足りない。
それらをつなげて初めて、何が起きているのか見えてきます。
NSAが示している主要な能力は、ざっくり言うと次の6つです。
関連する活動ログを取得する
SIEMなどに集約し、集中管理する
セキュリティとリスク分析を行う
ユーザーやエンティティの振る舞いを分析する
脅威インテリジェンスを統合する
動的ポリシーへつなげる
かなり分かりやすいです。
ログを取る。
集める。
分析する。
ふるまいを見る。
脅威情報で意味づける。
最後はポリシーに返す。
つまり、NSAが語っている可視化と分析は、ログ管理ではありません。
継続的に見て、判断し、ポリシーを変えられる状態を作ることです。
ここが本質です。
もう一つ大事なのは、NSAが「全部を闇雲に集めろ」とは言っていないことです。
重要なのは、関連性のあるログを優先し、標準化・正規化し、分析に使える形にすることです。
ログの量ではなく、判断に使えるかどうか。
ここはかなり現場向きの話です。
参考URL
https://media.defense.gov/2024/May/30/2003475230/-1/-1/0/CSI-VISIBILITY-AND-ANALYTICS-PILLAR.PDF
何が一番大事なのか
この柱で一番大事なのは、きれいなダッシュボードではありません。
ログの量でもありません。
判断に使える文脈を作ることです。
同じログでも、文脈があるかないかで価値が変わります。
このユーザーは一般ユーザーなのか、管理者なのか。
この端末は管理下なのか、野良端末なのか。
このアクセス先は重要システムなのか、通常のSaaSなのか。
このファイルは機密なのか、公開情報なのか。
このアクションは業務上よくあるのか、明らかに異常なのか。
ここまで見えないと、判断はできません。
ログはある。
でも文脈がない。
これは現場でかなりつらい状態です。
逆に、文脈がそろうと強いです。
「管理者が、未管理端末から、深夜に、普段触らない機密データへ大量アクセスした」
これはかなり危ない。
でも、それぞれのログを単独で見ていると、見逃す可能性があります。
だから可視化と分析で大事なのは、個別ログではなく相関です。
もっと言うと、相関したあとに優先順位をつけることです。
そして、優先順位をつけたあとに対応へ渡すことです。
ログを判断に変える。
この一文に尽きます。
SIEM、UEBA、SOARをどう分けて見るか
ここも混ざりやすいです。
可視化と分析の話になると、SIEM、UEBA、SOAR、XDR、NDR、EDR、ログ基盤、データレイクが一気に出てきます。
全部大事です。
でも、役割は分けて見た方がかなり分かりやすいです。
SIEMは、ログを集めて相関分析する側です。
複数のシステムからログを集め、検索し、ルールで検知し、インシデントとして扱えるようにする。
つまり、可視化と検知の土台です。
UEBAは、いつもと違う振る舞いを見る側です。
普段と違うログイン、いつも触らないデータ、急な大量ダウンロード、不自然な時間帯、異常なアクセス先。
ルールだけでは拾いにくい違和感を見るための考え方です。
SOARは、判断したあとに動く側です。
チケットを切る。通知する。隔離する。ブロックする。証跡を集める。担当者へ渡す。
これは次回の自動化の柱にかなり近い領域です。
雑に言うなら、
SIEMは集めて見つける。
UEBAはいつもと違うを見つける。
SOARは見つけたあとに動かす。
です。
この第6回では、主にSIEMとUEBAを中心に見ます。
SOARは大事です。
ただし、それは次回の自動化の柱で扱う方が自然です。
ここではまず、正しく見て、正しく意味づけるところまでを押さえます。
参考URL
現場で最低限そろえたいもの
可視化と分析の柱で最初に揃えたいのは、巨大なダッシュボードではありません。
まず土台です。
ここを飛ばすと、かなりの確率であとで詰まります。
一つ目は、集めるログの優先順位です。
全部集めたい気持ちは分かります。
でも、いきなり全部は無理です。
最初は、IdP、EDR、SSE/SASE、クラウド監査ログ、DLP、重要SaaSあたりから優先順位をつける方が現実的です。
どのログが、どの検知に必要なのかを先に決める。
ここが大事です。
二つ目は、ログの正規化と粒度です。
同じユーザーが、システムごとに別名で見える。
端末IDがつながらない。
アプリ名がバラバラ。
時刻がずれる。
この状態だと、相関分析はかなりつらいです。
ログは入っているのに、つながらない。
これは本当に起きます。
三つ目は、ユースケースから検知ルールを作ることです。
よくある失敗は、製品に入っているルールを全部有効にすることです。
これは危ないです。
アラートが増えすぎます。
まずは、自社で本当に見たいリスクから切るべきです。
不審ログイン、管理者権限の悪用、機密データの外部共有、マルウェア感染端末からのアクセス、クラウド設定変更、異常な大量ダウンロード。
こういうユースケースから作る方が回ります。
四つ目は、アラートの優先度設計です。
全部同じ重大度では現場は動けません。
誰が起こしたのか。
どの端末か。
どのデータか。
どの権限か。
どの資産か。
この文脈を足して、優先度をつける必要があります。
ゼロトラストの各柱が整っているほど、ここは強くなります。
五つ目は、一次対応の責任分界です。
アラートを誰が見るのか。
どこまでを情シスで見るのか。
どこからセキュリティへ上げるのか。
夜間・休日はどうするのか。
証跡はどこに残すのか。
ここが曖昧だと、可視化はしているのに対応が遅れる、という状態になります。
六つ目は、チューニングの習慣です。
検知ルールは一度作って終わりではありません。
誤検知を減らす。
見逃しを減らす。
業務変更に合わせる。
新しい攻撃手法に合わせる。
これを続けないと、可視化と分析の柱はすぐに鈍ります。
トレンドの製品は、Sentinel、XDR、NG-SIEM。
可視化と分析の柱で製品名を出すなら、従来型SIEMだけを並べても少し古く見えます。
ただし、だからといってSIEMを外してよいわけではありません。
ここは誤解しない方がいいです。
いま見るべきなのは、ざっくり言うとこの3つです。
Microsoft Sentinel
Palo Alto Networks Cortex XDR
CrowdStrike Falcon Next-Gen SIEM
この3つを並べると、可視化と分析の今の論点がかなり見えやすくなります。
従来のSIEMをどう進化させるのか。
XDRで複数の信号をどう相関するのか。
NG-SIEMでSOC運用をどう軽くするのか。
そして、ベスト・オブ・スイートで行くのか、ベスト・オブ・ブリードで組むのか。
ここです。
Microsoft Sentinelは、Microsoft 365、Entra、Defender、Purview、Azureとのつながりを作りやすいのが強みです。
すでにMicrosoft寄りの環境なら、ID、端末、クラウド、データ保護の信号をまとめやすい。
ゼロトラストの各柱をつなぐ観点では、やはり外しにくい選択肢です。
特に、Entra ID、Defender for Endpoint、Defender for Cloud、Purviewを使っている環境では、Sentinelはかなり自然に候補に入ります。
各製品の信号を同じ運用基盤に寄せやすいからです。
これは、いわゆるベスト・オブ・スイートの考え方に近いです。
一つひとつの専門機能を最高峰でそろえるというより、既存のMicrosoft基盤を活かして、運用と連携をシンプルにする。
この発想です。
Palo Alto Networks Cortex XDRは、エンドポイントだけを見る道具ではありません。
エンドポイント、ネットワーク、クラウド、IDなどの信号をつなげて、攻撃の流れを検知・優先順位付けする方向に寄っています。
つまり、単発のアラートではなく、複数の信号をまとめて「これは本当に危ないのか」を見ようとする考え方です。
これはゼロトラストと相性がいいです。
なぜか。
ゼロトラストでは、ID、端末、ネットワーク、ワークロード、データの信号が別々に出ます。
それを単独で見るだけでは、判断が弱い。
Cortex XDRのようなXDRは、それらの信号を相関させて、攻撃の全体像を見ようとする方向です。
CrowdStrike Falcon Next-Gen SIEMは、従来型SIEMを置き換える、または補完する流れとして見やすいです。
CrowdStrikeはEDRの強い文脈を持っています。
そこに、他のログやセキュリティ信号を取り込んで、SOCの検知・調査・対応をより速く回す方向です。
ここで大事なのは、NG-SIEMという言葉です。
従来のSIEMは、ログを大量に集めて検索・相関する発想が中心でした。
NG-SIEMは、そこにクラウドスケール、リアルタイム検索、AI、EDR由来の文脈、ワークフロー自動化を足して、運用を軽くしようとする方向です。
Palo Alto NetworksやCrowdStrikeのように、特定領域で強い製品を組み合わせていく考え方は、ベスト・オブ・ブリードに近いです。
EDRはこの製品、SASEはこの製品、SIEM/XDRはこの製品、という形で、各領域の強いものを選んで組む。
うまく設計できれば強いです。
ただし、連携設計、ログ正規化、運用責任の分界が甘いと、製品は強いのに現場がつながらない、ということも起きます。
逆に、ベスト・オブ・スイートは、連携と運用をシンプルにしやすいです。
Microsoftに寄せるなら、Sentinel、Defender、Entra、Purviewをつなげる設計はかなり現実的です。
ただし、すべてをスイートに寄せれば必ず最適、という話でもありません。
自社の既存環境、運用スキル、ログ量、監視体制、SOCの成熟度によって見え方は変わります。
つまり、この項目で言いたいのは、製品ランキングではありません。
Sentinel、XDR、NG-SIEMを比較しながら、自社がベスト・オブ・スイートで運用を寄せるのか、ベスト・オブ・ブリードで強い製品を組み合わせるのかを判断すること。
ここです。
このテーマはかなり大きいので、ベスト・オブ・ブリードとベスト・オブ・スイートの詳細は別記事で扱った方がいいです。
今回の記事では、可視化と分析の柱において、製品選定そのものよりも「判断に変えられる運用設計」が重要だ、というところまで押さえれば十分です。
参考URL
現場でよくある失敗は、だいたい同じ
一番多いのは、ログを集めて終わることです。
これは本当によくあります。
コネクタはつながった。ログも入っている。検索もできる。
でも、検知ルールが弱い。誰が見るか曖昧。対応フローがない。
これでは柱になりません。
次に多いのが、アラートが多すぎて誰も見なくなることです。
最初からルールをたくさん有効にする。
重大度の見直しをしない。
誤検知を放置する。
そうすると、現場は疲れます。
そして、だんだん見なくなります。
ここはかなり危ないです。
さらに多いのが、ログはあるのに文脈がないことです。
このユーザーは管理者なのか。
この端末は管理下なのか。
このデータは機密なのか。
このアプリは重要なのか。
ここが分からないと、アラートの優先順位がつきません。
ログはある。でも判断できない。
これはかなりつらい状態です。
もう一つは、SOC任せにして現場が切り離されることです。
検知はSOCが見る。
でも端末を触るのは情シス。
アプリを直すのは開発。
権限を直すのは業務部門。
この分断があると、検知しても直りません。
可視化と分析は、見る人だけの話ではなく、直す人との接続まで含めて設計すべきです。
最後に、チューニングしないことです。
検知ルールを作ったまま放置する。
ログ形式が変わっても気づかない。
業務の変化に追従しない。
新しい攻撃手法に合わせない。
こうなると、最初は動いていた検知も、だんだん鈍ります。
可視化と分析は、入れて終わりではありません。
運用し続けてこそ価値が出ます。
この柱が整うと、自動化の柱が回り始める
可視化と分析の柱が整うと、次はいよいよ自動化の柱です。
ここから先は、見つけたものをどう動かすか、という話になります。
なぜか。
見えていないものは自動化できません。
優先度がついていないものも自動化できません。
誤検知が多いものを自動化すると、業務影響が出ます。
逆に、検知の品質が高く、文脈がついていて、対応手順が決まっていれば、自動化はかなり効きます。
たとえば、感染疑い端末を隔離する。
高リスクログインを再認証させる。
外部共有を自動で解除する。
チケットを起票する。
担当部門へ通知する。
これらは、可視化と分析が整っているからできることです。
つまり、第6回の柱は単なるログの話ではありません。
次の自動化を安全に動かすための前提です。
ここが弱いと、自動化は怖くて動かせません。
ここが強いと、自動化はかなり現実的になります。
まとめ
可視化と分析の柱は、ログを集める柱ではありません。
各柱から出る信号を、判断と対応に変える柱です。
NSAの整理で見ても、この柱はログ取得、SIEM集約、リスク分析、UEBA、脅威インテリジェンス、動的ポリシーまでつながる話です。
ログをためるだけではなく、見て、つなげて、意味づけて、ポリシーや対応へ返していく。
ここが本質です。
いまのトレンドとしても、アイデンティティやSASEは先に進みやすい一方で、XDR/SOARや動的なアクセス制御、セッション単位の検証・認可はまだ課題が残っています。
つまり、可視化と分析は、これから差が出る領域です。
最初に全部完璧である必要はありません。
でも、ログを集めただけで満足すると、だいたいあとで詰まります。
ここはかなりの確率で詰まります。
だから先に手を打つ。これが大事です。
ログを倉庫にするのか。
判断の材料にするのか。
差がつくのは、導入後の運用設計です。
そしてこの柱が整うと、最後の自動化がようやく現実になります。
そう思います。
恐縮でした。
次回はこちら
