[連載]それほんとに自動化なのか？？何でもかんでも自動で止める前に、まず手順を固めるべき。[第7回]
恐縮です。
ここまでできている企業さんはほんとに一握り。
ゼロトラストの7つの柱も、いよいよ最後です。
アイデンティティで「誰か」を見る。
デバイスで「どの端末か」を見る。
ネットワークで「どこへ到達させるか」を制御する。
ワークロードで「アプリと実行環境」を見る。
データで「何を守るか」を決める。
可視化と分析で「何が起きているか」を判断する。
前回はこちら。
そして最後に来るのが、自動化です。
ここまで来ると、どうしてもこう考えたくなります。
アラートが出たら自動で止めたい。
感染疑い端末を自動隔離したい。
危ない共有を自動解除したい。
高リスクログインを自動ブロックしたい。
チケットも自動で起票したい。
もちろん、それは正しい方向です。
人手だけで全部を見るのは無理です。
ログは増える。アラートも増える。SaaSも増える。端末も増える。クラウドも増える。
この状態で、すべてを人間の注意力だけに頼るのはかなり厳しいです。
でも、ここで一番やってはいけないのが、自動化そのものをゴールにすることです。
自動化は強いです。
かなり強い。
ただし、間違った判断を自動化すると、被害も自動で広がります。
誤検知で業務を止める。
必要なアクセスを遮断する。
原因が分からないまま隔離する。
誰も戻し方を知らない。
これでは守っているのではなく、現場を壊しているだけです。
だから先に言い切ります。
自動化の柱は、何でも自動で止める柱ではありません。
判断できるものを、決めた手順で、安全に速く動かす柱です。
自動化で大事なのは、速さだけではありません。
正確さ。
再現性。
証跡。
責任分界。
ロールバック。
例外管理。
ここまで含めて設計する必要があります。
自動化は最後の柱です。
でも、最後に余裕があればやるおまけではありません。
前の6つの柱で得た判断材料を、実際の対応に変えるための出口です。
ここが整って、ゼロトラストはようやく「見える」から「動ける」に変わります。
参考URL
https://media.defense.gov/2024/Jul/10/2003500250/-1/-1/0/CSI-ZT-AUTOMATION-ORCHESTRATION-PILLAR.PDF
NSAは、自動化とオーケストレーションをどう見ているか
ここで押さえておきたいのが、NSAの「Automation and Orchestration」ガイダンスです。
NSAは2024年に、ゼロトラストの最後の柱として、自動化とオーケストレーションに関する文書を公開しています。
ここで大事なのは、NSAが自動化を単なる省力化として見ていないことです。
NSAの整理では、自動化とオーケストレーションは、企業全体の定義済みプロセスとセキュリティポリシーに基づいて、セキュリティ上のアクションや反応を自動化する能力として扱われています。
焦点は、スピードとスケールです。
つまり、手作業を減らすだけではありません。
同じ判断を、同じ手順で、速く、広い範囲に適用できるようにする。
これが自動化の本質です。
NSAの文書で特に実務的なのは、Automation と Orchestration を分けているところです。
Automationは、反復的なタスクをソフトウェアで制御することです。
たとえば、アラートが出たら情報を収集する。
IPやハッシュを照会する。
チケットを起票する。
特定条件なら通知する。
こういう単体タスクの自動化です。
Orchestrationは、複数のITプロセスやワークフローを調整することです。
たとえば、EDRで端末を隔離し、IdPでセッションを無効化し、SASEで通信を遮断し、チケットを起票し、担当者へ通知し、証跡を保存する。
こういう複数ツール・複数部門をまたぐ流れをつなぐことです。
ここはかなり大事です。
自動化は「ボタンを押さなくてよくする」だけではありません。
オーケストレーションまで行くと、対応全体の流れを標準化する話になります。
NSAが言っている方向性は、かなり現場向きです。
定型的な作業を自動化することで、人間はより高度な調査や、攻撃者の戦術・技術・手順に関わる異常の分析に集中できる。
つまり、人を不要にするのではなく、人が見るべきものに集中できる状態を作るということです。
これは大きいです。
自動化の目的は、人を減らすことではありません。
人の判断力を、重要な場面に残すことです。
参考URL
https://media.defense.gov/2024/Jul/10/2003500250/-1/-1/0/CSI-ZT-AUTOMATION-ORCHESTRATION-PILLAR.PDF
自動化が進まない理由は、ツール不足ではない
ここはかなり現実を見た方がいいです。
自動化は大事です。
でも、現場では思ったほど進みません。
理由は、ツールがないからではありません。
むしろツールはあります。
SOARもある。SIEMのプレイブックもある。EDRの自動隔離もある。IdPのリスクベース制御もある。SASEの自動ブロックもある。ITSM連携もある。
それでも進まない。
なぜか。
自動化できるほど、手順が固まっていないからです。
誰が判断するのか。
どの条件なら止めるのか。
どこまで自動でやるのか。
どこから人の承認を入れるのか。
止めたあと誰に連絡するのか。
業務影響が出たら誰が戻すのか。
証跡はどこに残すのか。
例外はどう扱うのか。
ここが曖昧なまま自動化すると危ないです。
だから現場は怖くなる。
怖いから、通知だけ自動化する。
通知だけなので効果が出にくい。
効果が出ないから、自動化プロジェクトが止まる。
この流れはかなり起きます。
自動化が進まない会社は、技術が弱いというより、判断と手順が標準化されていないことが多いです。
そして、それは恥ずかしいことではありません。
むしろ普通です。
だから、最初から自動ブロックを目指さなくていいです。
まずは情報収集を自動化する。
次に通知を自動化する。
次にチケット起票を自動化する。
次に承認付きで隔離する。
最後に低リスク・高確度のものだけ自動実行する。
この順番の方が、かなり現実的です。
自動化は、いきなり強くしない。
小さく始めて、事故らない範囲で広げる。
ここが重要です。
SOAR、プレイブック、IT自動化をどう分けて見るか
ここも混ざりやすいです。
自動化の話になると、SOAR、プレイブック、ITSM、RPA、EDR自動隔離、IdPの条件付きアクセス、SASEの自動ブロックが一気に出てきます。
全部、自動化っぽいです。
でも、役割は分けて見た方がいいです。
SOARは、セキュリティ対応をつなぐ基盤です。
アラートを受ける。
情報を集める。
担当を割り当てる。
チケットを作る。
複数ツールへアクションする。
対応記録を残す。
この一連の流れを標準化し、自動化・半自動化するための仕組みです。
プレイブックは、対応手順そのものです。
フィッシングなら何を見るか。
マルウェア疑いなら何を確認するか。
高リスクログインなら何を止めるか。
外部共有なら誰に確認するか。
つまり、現場の対応を再現可能な手順にしたものです。
IT自動化は、セキュリティ外の運用も含めて動かす仕組みです。
端末の構成変更、アカウント無効化、チケット連携、資産管理更新、パッチ適用、権限棚卸し、ワークフロー承認。
セキュリティだけで閉じない部分を動かすために必要です。
雑に言うなら、
SOARは対応をつなぐ。
プレイブックは手順を決める。
IT自動化は実際の業務運用まで動かす。
です。
ここを分けて考えると、自動化の設計はかなり見えやすくなります。
SOAR製品を入れただけでは、プレイブックは勝手に育ちません。
プレイブックがあっても、権限や承認がなければ動かせません。
ITSMや資産管理とつながっていなければ、現場の復旧や連絡は止まります。
つまり、自動化はツール導入ではなく、手順・権限・連携・責任の設計です。
ここを外すと、かなり危ないです。
現場で最低限そろえたいもの
自動化の柱で最初に揃えたいのは、派手な自動ブロックではありません。
まず土台です。
ここを飛ばすと、かなりの確率で事故ります。
一つ目は、自動化する対象の選定です。
何でも自動化しようとしない。
最初は、繰り返しが多く、判断条件が明確で、業務影響が小さいものから始めるべきです。
たとえば、アラート情報の収集、チケット起票、担当通知、ハッシュ照会、ユーザー情報の取得、過去ログの検索。
このあたりは始めやすいです。
二つ目は、プレイブックの標準化です。
誰がやっても同じ確認ができるか。
判断ポイントは明文化されているか。
証跡をどこに残すか。
エスカレーション条件はあるか。
ここがないと、自動化以前に対応品質が揺れます。
三つ目は、人の承認を入れる境界です。
全部自動で止める必要はありません。
むしろ最初は、人の承認を挟むべきところを決める方が大事です。
端末隔離、アカウント停止、外部共有解除、通信遮断、権限剥奪。
こういう業務影響があるアクションは、承認付きで始める方が現実的です。
四つ目は、ロールバック手順です。
止めたあと、どう戻すのか。
誰が戻すのか。
戻してよい条件は何か。
戻した証跡はどこに残すのか。
ここがない自動化はかなり危ないです。
自動で止められるのに、手動でしか戻せない。
これは現場を疲弊させます。
五つ目は、権限と接続先の管理です。
SOARや自動化基盤は、強い権限を持ちがちです。
IdPを操作する。EDRを操作する。SASEを操作する。チケットを作る。クラウド設定を変える。
だから、自動化基盤そのものの権限管理と監査が必要です。
ここを甘く見ると、自動化基盤が強すぎるリスクになります。
六つ目は、効果測定です。
自動化した結果、何が良くなったのか。
初動時間が短くなったのか。
誤対応が減ったのか。
手作業が減ったのか。
対応漏れが減ったのか。
業務影響は増えていないか。
これを見ないと、自動化が価値を出しているのか分かりません。
[画像④：自動化の柱で最低限そろえたいもの]
※ 図の要素：対象選定 → プレイブック標準化 → 承認境界 → ロールバック → 権限管理 → 効果測定 の流れ
※ キャプション案：最初から自動ブロックを狙わず、まずは安全に動かせる土台を作る
この柱では、無理に製品名を前に出さない
自動化の柱では、あえて代表製品名を前に出しすぎない方がいいと思っています。
理由はシンプルです。
この領域は、まだ多くの現場で「製品を入れて自動化を回す」段階まで来ていないからです。
SIEMやEDRやSASEは、製品導入の話にしやすいです。
入れる対象も比較的見えやすい。
運用課題はもちろんありますが、何を導入するのかは伝わりやすいです。
でも、自動化は違います。
SOARやプレイブックという言葉は出ます。
自動隔離、自動ブロック、チケット起票、通知連携も魅力的です。
ただ、現場で本当に詰まるのは製品選定ではありません。
詰まるのは、
何を自動化してよいのか
どこまで自動で止めてよいのか
誰の承認が必要なのか
誤検知だったとき誰が戻すのか
業務影響を誰が判断するのか
ここです。
つまり、まだ製品トレンドを語るより先に、運用成熟度を語る段階です。
この状態で製品名を並べると、「この製品を入れれば自動化できる」と見えてしまう。
それはかなりミスリードになります。
自動化の柱で最初に見るべきは、製品ではありません。
対応手順が標準化されているか。
判断条件が言語化されているか。
止める・戻す・記録する流れが決まっているか。
現場部門とセキュリティ部門の責任分界が決まっているか。
ここです。
そして、ここで一つ現実的な選択肢があります。
SOCサービスとして外に出すことです。
自社で24時間見る。
自社でプレイブックを作る。
自社でチューニングする。
自社で一次対応する。
自社で自動化基盤を運用する。
これを全部やるのは、かなり重いです。
特に、専任SOCがない組織や、セキュリティ担当が少ない組織では、自動化以前に監視と一次判断で詰まります。
その場合、無理に自社だけでSOARを回そうとするより、MDRやマネージドSOCのような外部サービスを使い、監視、一次分析、初動連絡、推奨対応まで外に出す選択肢は十分あります。
ここで大事なのは、丸投げではありません。
外に出す場合でも、社内で決めるべきことは残ります。
どのアラートを通知してほしいのか。
どの条件なら緊急扱いにするのか。
誰に連絡するのか。
夜間休日はどうするのか。
端末隔離やアカウント停止は外部に任せるのか、社内承認を挟むのか。
証跡やレポートをどう受け取り、改善につなげるのか。
ここを決めないままSOCサービスを入れても、結局は「通知は来るが社内で動けない」状態になります。
だから、外出しする場合でも、判断基準と対応フローは自社で持つ必要があります。
自動化のトレンドは、これからもっと来ると思います。
ただ、今の現場感としては、いきなり製品名を並べるより、
自社で回すのか、SOCサービスとして外に出すのか。
どこまでを自動化し、どこから人の判断を残すのか。
この切り分けを先に考えた方がいいです。
この柱は、まだ「どの製品が強いか」より、どの運用なら事故らずに動かせるかの方が大事です。
ここを間違えない方がいいです。
現場でよくある失敗は、だいたい同じ
一番多いのは、自動化を入れて終わった気になることです。
これは本当によくあります。
プレイブックは作った。通知も飛ぶ。チケットも起票される。
でも、誰が見るのか曖昧。止める条件が曖昧。戻す手順がない。
これでは柱になりません。
次に多いのが、いきなり自動ブロックから始めることです。
これはかなり危ないです。
誤検知でアカウントを止める。
端末を隔離する。
通信を遮断する。
外部共有を消す。
業務影響が出たときに、なぜ止まったのか分からない。
誰も戻せない。
この状態は避けるべきです。
さらに多いのが、プレイブックが現場の手順とズレていることです。
セキュリティ担当が作った理想のフロー。
でも、実際の情シスや業務部門の動きと合っていない。
連絡先が違う。承認者が違う。復旧手順が違う。
こうなると、自動化は現場で使われません。
もう一つは、例外処理がないことです。
役員端末、工場端末、重要会議中の端末、業務委託、海外拠点、24時間稼働システム。
自動化は標準フローには強いですが、例外に弱いです。
例外をどう扱うかを決めていないと、必ず揉めます。
最後に、自動化基盤の権限が強すぎることです。
SOARや自動化基盤は、いろいろなツールを操作します。
つまり、侵害されたらかなり危ない。
自動化基盤そのものにMFA、最小権限、監査ログ、変更管理が必要です。
自動化を守らない自動化は、本当に危ないです。
自動化で、7つの柱がつながる
自動化の柱が整うと、7つの柱がようやく一つの流れになります。
IdPで高リスクログインを検知する。
EDRで端末の不審挙動を検知する。
SSE/SASEで通信やアクセスを制御する。
ワークロードでクラウド設定や実行リスクを見つける。
DLPで機密データの外部共有を検知する。
SIEMやXDRでそれらを相関する。
そして、SOARや自動化基盤で必要な対応へつなげる。
これがつながると強いです。
単発の製品導入ではなく、判断と対応が流れになります。
ただし、全部を一気につなぐ必要はありません。
むしろ、一気につなぐと危ないです。
まずは小さなユースケースから始める。
たとえば、フィッシング報告の一次調査。
高リスクログインの通知とチケット起票。
感染疑い端末の情報収集。
機密ファイル外部共有の確認依頼。
このあたりから始める方が現実的です。
小さく始める。
効果を見る。
誤検知を潰す。
承認境界を見直す。
少しずつ自動実行を広げる。
この流れが一番強いです。
自動化は、ゼロトラストの最後の柱です。
でも、ゴールテープではありません。
ここから、運用改善のサイクルが始まります。
まとめ
自動化の柱は、何でも自動で止める柱ではありません。
判断できるものを、決めた手順で、安全に速く動かす柱です。
NSAの整理で見ても、自動化とオーケストレーションは、定義済みのプロセスとセキュリティポリシーに基づいて、セキュリティ上のアクションや反応を速く、広く、再現性高く動かすためのものです。
単なる省力化ではありません。
自動化は強いです。
でも、手順が弱いまま自動化すると危ない。
検知が弱いまま自動化しても危ない。
ロールバックがないまま自動化しても危ない。
権限管理が甘いまま自動化しても危ない。
だから最初にやるべきは、自動ブロックではありません。
対象を選ぶ。
プレイブックを標準化する。
承認境界を決める。
ロールバックを用意する。
権限を絞る。
効果を測る。
この土台を作ることです。
ゼロトラストは、見えて終わりではありません。
判断して、動いて、直して、また改善する。
自動化の柱は、その最後の一歩です。
ここまで来て、7つの柱はようやくつながります。
アイデンティティから始まり、自動化で運用に落ちる。
この流れが、現場で回るゼロトラストの形だと思います。
恐縮でした。
自分で書きながらそうだよなぁとか思いながら書いた連載でした。
全体を俯瞰した最終回をどこかで記載しようと思います。
やっぱりセキュリティってむずかしい。
