[連載]なにそれ、おいしいの？EDRの役目。EDRが割と先に入る理由と、UEMと分けて考えるポイント[第2回]

恐縮です。

ゼロトラストの話で、アイデンティティの次に一気に迷いが出るのがここです。
EDRを先に入れるのか。SSE/SASEを先に走らせるのか。
現場はだいたいここで割れます。

前回はこちら。

でも、私の立場はかなり明確です。
先にEDRです。
なぜか。端末の現実が見えるからです。
何が動いているのか。どの端末が危ないのか。侵害の痕跡はあるのか。止めるべきか、様子を見るべきか。
この判断材料が増える。
ここが大きい。

逆に、ここを飛ばしてネットワーク制御だけ先に走ると危ない。
ルールは増える。でも、端末の現実が見えていない。
すると、結局はざっくり許可、広めの例外、現場頼みの運用に戻りやすい。
これはかなり苦しいです。

ただし、ここで勘違いしてはいけません。
EDRを入れたからゼロトラストになったわけではありません。
EDRは強い。かなり強い。
でも、あくまでデバイスの柱を前に進める部品です。
柱そのもの全部ではない。ここを混ぜると、設計が簡単にぶれます。

ゼロトラストのデバイスの柱で本当に必要なのは、端末で何が起きているかを見えるようにすることと、その端末を信頼してよい状態に保つことです。
前者はEDRが得意です。
後者はUEMやMDMが得意です。
ここを分けて考えないと、EDRだけ入れて満足するか、逆に管理だけきれいで侵害に弱いかのどちらかに寄りやすくなります。

参考URL

もちろんEDRはゼロトラストそのものではない

EDRは、端末の検知と対応のための仕組みです。
ざっくり言えば、端末で何が起きているかを継続的に観測し、怪しい挙動を見つけて、調べて、止めるための道具です。

ここはかなり重要です。
EDRの本体は、アンチウイルスの延長ではありません。
もちろん防御もします。
ただ、それ以上に価値が大きいのは、侵害の痕跡や不審な振る舞いを拾い、調査と初動対応につなげられることです。

ゼロトラストの文脈で見ると、EDRが担うのは「この端末はいま信用してよいのか」を判断するための材料を増やすことです。
マルウェア感染の有無、怪しいプロセス、横展開の兆候、脆弱性の状況、隔離の必要性。
こうした信号があるから、端末をただの箱として扱わずに済みます。

ここが大事です。
ゼロトラストは、きれいな理想図の話ではありません。
信用していいかを、雑に決めないための設計です。
だとすると、端末の実態が見えないままでは話にならない。
EDRは、その「見えない」をかなり強く崩してくれます。

ただし、EDRだけでは足りません。
端末が管理下かどうか、暗号化されているか、OSが更新されているか、証明書が正しく入っているか、業務アプリが入っているか、といった日常の統制はEDRだけでは閉じません。
だから、EDRは強いけれど万能ではない。
この位置づけを先に押さえた方が、あとでぶれません。

参考URL

それでもEDRが先に入りやすい理由

それでも現場では、EDRが先に入ることが多いです。
これはかなり自然です。
むしろ、そうなりやすい理由があります。

一番の理由は、効果が見えやすいからです。
入れたその日から、どの端末がいるか、何が動いているか、どんな警告が出ているかが見え始める。
それまで「たぶん大丈夫」で回していたものが、急に現実の数字とログで見えるようになります。
この変化は大きい。
現場の温度が変わります。

二つ目は、インシデント対応の質が上がるからです。
感染したかもしれない。怪しい通信がある。ユーザーから端末がおかしいと言われた。
こういうとき、EDRがあるかないかで初動はかなり変わります。
見えないものは調べられない。
調べられないものは止められない。
ここは厳しいですが、現実です。

三つ目は、SSE/SASEや条件付きアクセスの前提を作りやすいからです。
ゼロトラストでは、最終的に端末状態をアクセス制御へつなげたい。
そのとき、端末側の信号が弱いと制御ルールが雑になります。
管理下端末なのか。リスクが高いのか。隔離すべきなのか。そこが曖昧なままでは、ネットワーク制御も結局は広めに許可するしかなくなる。

だから、ここは順番の話としてかなり大きいです。
設計としてはSSE/SASEを並行で考えてよい。
でも、現場で最初に地面を固めるのはEDRの方が強い。
見えるようになるから、次の制御へ進める。
この順番はかなり自然です。

EDRとUEMは、似ているようで役割が違う

ここは現場で本当によく混ざります。
どちらも端末に入る。どちらも状態を見る。どちらも制御っぽいことをする。
でも、役割はかなり違います。

EDRは、挙動を見る仕組みです。
何が動いたか。怪しいか。攻撃っぽいか。止めるべきか。調べるべきか。
つまり、侵害や不審挙動に強い。

UEMは、状態を揃える仕組みです。
管理下か。OSは最新か。暗号化されているか。構成プロファイルは入っているか。業務アプリは入っているか。証明書は正しいか。
つまり、準拠状態や運用統制に強い。

この違いを雑に言うなら、
EDRは見つけて止める側。
UEMは揃えて守らせる側。
です。

ここを混ぜると危ないです。
EDRだけで日常統制まで全部やろうとして詰まる。
逆に、UEMだけで端末は管理できているから大丈夫だと思い込んで、侵害の現実が見えていない。
この二つは、どちらもかなり起きやすい。

ゼロトラストのデバイスの柱では、この両方が必要です。
EDRだけだと、侵害は見えるが日常統制が弱い。
UEMだけだと、管理はきれいだが攻撃の現実が見えにくい。
だから、どちらが上かではなく、役割が違うと理解した方がうまくいきます。

参考URL

現場で最低限そろえたいもの

EDR編として最初に揃えたいのは、派手な機能よりも、まず土台です。
ここを飛ばすと、だいたいあとで崩れます。

一つ目は、端末の棚卸しと配布対象の明確化です。
どの端末に入れるのかが曖昧だと、検知以前に穴が残ります。
社給PC、BYOD、サーバー、VDI、開発端末、検証機。どこまでを対象にするかを先に切らないと、導入しても coverage が崩れます。
ここをふわっと始めると危ないです。
「だいたい入っている」は、現場では一番危ない状態の一つです。

二つ目は、アラートを見る責任の置き場です。
EDRは入れた瞬間に価値が出る一方で、アラートを放置するとただの騒音になります。
誰が一次確認するのか。夜間はどうするのか。どこまでを情シスで持ち、どこからをセキュリティ担当へ上げるのか。ここを最初に決めた方がいいです。
責任の置き場が曖昧なEDRは、かなりの確率で形骸化します。

三つ目は、隔離と調査の手順です。
EDRの価値は、見えるだけではなく動けることにあります。
ただし、隔離を押すと業務影響が出ることもある。
だからこそ、どの条件なら隔離するか、誰が承認するか、復旧時に何を確認するかを事前に決めておく必要があります。
この判断が場当たりになると、現場は必ず疲れます。

四つ目は、IdPとUEMとの接続を意識することです。
この端末は誰のものか。
このユーザーはどの認証強度で入ってきたか。
この端末は管理下か。
ここがつながると、EDRの信号を単独の検知ではなく、アクセス制御に使える材料へ変えやすくなります。
ここがつながらないと、せっかく見えた端末信号が“良いログ”で終わりやすい。
それはもったいないです。

五つ目は、例外を先に洗い出すことです。
古いOS、オフライン端末、検査装置、特殊ソフト、役員端末、開発者の管理者権限、工場系PC。
現場が詰まるのは、たいてい標準端末ではなく例外側です。
最初から全部きれいにはできません。
でも、見えていない例外は必ずあとで事故になります。
例外は悪ではありません。
ただし、見えていない例外はかなり危ない。
ここは分けて考えた方がいいです。

代表的な製品はこの3つから見れば外しにくい

EDRで代表例を3つ挙げるなら、まずは
Microsoft Defender for Endpoint
CrowdStrike Falcon
SentinelOne Singularity Endpoint Security
でよいと思います。
※余談ですが少し前はサイバーリーズンもよかったんですよ。買収されたけど

ここでも言いたいのは、どれが絶対に一番かではありません。
現場で比較対象に上がりやすく、考え方の違いを見やすい3つ、という意味です。

Microsoft Defender for Endpointは、Microsoft 365、Intune、Entra、Sentinelとつなげやすいのが強みです。
すでにMicrosoft寄りの環境なら、端末・認証・ログの流れをまとめやすい。
デバイスの柱を他の柱とつなぐ観点ではかなり見やすいです。
既存資産がMicrosoftに寄っているなら、かなり強く候補に入ります。

CrowdStrike Falconは、単一エージェントとクラウドネイティブな運用の見やすさで比較対象になりやすいです。
異種環境が多くても比較しやすく、EDRを中心に端末可視化と対応を整えたい組織で候補に上がりやすいです。
「まずEDRを強く入れたい」という発想と相性がいいです。

SentinelOneは、自動化やロールバックを含めた対応の見せ方が分かりやすく、運用負荷を意識する組織で比較対象になりやすいです。
現場で「どこまで自動で動かしたいか」という観点を持つと見やすい製品です。
止めるところまで含めて考えたい現場では比較しやすいです。

それと別に、UEM側の代表例としては
Microsoft Intune
Omnissa Workspace ONE UEM
Jamf Pro
あたりを押さえておくと、EDRとUEMの切り分けがかなり見えやすくなります。

大事なのは、デモがきれいかどうかではありません。
自社の例外端末、運用体制、既存環境を含めて、本当に回るかどうか。
ここで見ると、製品の見え方はかなり変わります。

参考URL

現場でよくある失敗は、だいたい同じ

一番多いのは、EDRを入れて終わった気になることです。
これは本当によくあります。
エージェントは入った。アラートも出る。管理画面も見える。ここまでは進んだ感じがする。
でも、誰が見るのかが曖昧。隔離ルールがない。棚卸しが汚い。例外端末が野放し。これでは柱になりません。

次に多いのが、アラート疲れで形骸化することです。
最初は一生懸命見るのですが、ノイズが多い、優先度が分からない、だんだん誰も深掘りしない。そうすると、EDRは“入っているだけの高い道具”になりやすいです。
ここは本当に起きます。
だから、導入より運用設計の方が重い、と最初から思っておいた方がいいです。

さらに多いのが、UEMやIdPとつながっていないことです。
感染っぽい端末がある。
でもそれが誰の端末か曖昧。
管理下か分からない。
業務委託か社員か分からない。
この状態だと、検知はできても判断が遅れます。
判断が遅れると、結局は止めるのも遅れる。
ここはかなり痛いです。

もう一つは、例外端末が聖域になることです。
古い端末だから仕方ない。業務都合だから外す。検査装置だから別管理。ここまでは現実です。
ただ、その例外が可視化もされず、定期見直しもなく、永続例外になると一気に危ないです。
ゼロトラストは完璧主義ではなくてもいいですが、例外を放置してよいわけではありません。
ここを甘く見ると、だいたいあとで苦しくなります。

この柱が整うと、次のネットワークの柱が回り始める

デバイスの柱が整うと、次はネットワークの柱が一気に現実的になります。
ここで景色が変わります。

なぜか。
SSE/SASEやZTNAで本当にやりたいのは、
①誰が
②どの端末で
③どの条件なら
④どこへ到達できるか
を制御することだからです。

はい、そうですね。①②はそろいました。(IdPとEDR）

ここで端末信号が弱いと、結局はネットワークの場所やざっくりしたグループで許可するしかなくなります。
逆に、EDRとUEMが整っていて、IdPともつながっていると、管理下端末のみ許可、リスク端末は再認証、感染疑い端末は遮断、といった設計がかなり現実的になります。

つまり、EDRは単なる端末防御の話ではありません。
デバイスの柱を前に進めて、次のネットワーク制御を細かくするための足場でもあります。
ここが見えると、EDRを先に入れる意味がかなり腹落ちしやすくなります。

ここは大きいです。
ネットワーク制御を賢くしたいなら、先に端末信号を強くする。
この順番を外すと、ポリシーだけ立派で、実態はかなり雑、という状態になりやすい。
だから、EDRは単独導入で終わる話ではなく、次の柱に効かせる前提として見た方がいいです。

まとめ

EDRは、ゼロトラストそのものではありません。
でも、ゼロトラストのデバイスの柱を前に進めるうえで、かなり強い起点です。

理由はシンプルです。
端末の現実が見えるようになるから。
そして、見えるようになることで、次の制御に進めるからです。

ただし、EDRだけでは柱は完成しません。
EDRは見つけて止める側。
UEMは揃えて守らせる側。
この役割の違いを押さえて、IdPともつなぎながら設計すると、デバイスの柱はかなり強くなります。

最初に全部完璧である必要はありません。
でも、棚卸し、アラート運用、隔離手順、例外管理、このあたりを曖昧にしたまま進めると、だいたいあとで詰まります。
ここはかなりの確率で詰まります。
だから先に手を打つ。これが大事です。

だから、アイデンティティの次にEDRが来る、という順番はかなり自然です。
見えるようにして、止められるようにして、そこからネットワーク制御へつなげる。
この流れは、やはり強いと思います。

恐縮でした。