2026年6月13日
ゼロトラストWGリーダー　諸角昌宏

本ブログは、CSAジャパンとしての正式な見解ではなく、あくまで筆者の個人的な意見としてまとめたものである。しかしながら、この問題はクラウドセキュリティに関わる人に幅広く関係することとして、このCSAジャパン・ブログに掲載させていただく。皆さんの屈託のないご意見をいただければ幸いである。

はじめに：ツールは増えたのに、不安は減らない

セキュリティ対策の一覧表を開くとそこに並んでいるのは、EDR、SASE、WAF、SIEM、メールセキュリティ……。気がつけば、対策の一覧が「導入済み製品の一覧」になってはいないだろうか。

毎年新しい脅威レポートを読み、新しい製品を検討し、予算を確保し、導入する。それでも不安は消えない。次の脅威が報じられれば、また次の製品の検討が始まる。多くの組織で、セキュリティはこのサイクルの中にあると思える。

本ブログでは、このサイクルの原因が担当者の問題ではなく、「セキュリティを脅威への対抗として捉える」という捉え方そのものにあることを示し、意思決定の起点に置く問いを入れ替えることで、やるべきことの順番と、それを組織に通す力がどう変わるかを提案してみたい。

第1章. 脅威を主語にすると、対応は「脅威ごとの足し算」になる

セキュリティの議論は、多くの場合「脅威」から始まる。新型ランサムウェア、サプライチェーン攻撃、AIを悪用した攻撃。脅威を主語に置くと、問いは自動的に「この脅威をどう防ぐか」になる。

ここに見落とされがちな構造がある。脅威はマルウェア、エクスプロイト、DDoSといった、個別の技術的な現象として記述される。個別の脅威の粒度で立てられた問いは、その脅威に対応する個別の対策——検知ルールの追加、設定の強化、訓練、そして最も典型的には対策製品の導入——を引き寄せることになる。しかし、いずれの形を取るにせよ、対応は脅威ごとの足し算になる。フィッシングにはメール対策と訓練を、ランサムウェアにはEDRとバックアップを、という具合に、脅威と対策の対応表を埋めていく発想である。

もちろん、脅威の認識から組織の足腰に関わる対応に至る場合もある。ランサムウェアの被害事例を見て、バックアップと復旧体制の見直しに取り組んだ組織は実際にある。しかし注意深く見ると、そこでは問いがいつの間にか「この脅威をどう防ぐか」から「攻撃されても戻ることができるか」に翻訳されている。この翻訳が起きなければ、対応は最短距離にある個別対策の追加——多くの場合は製品の導入——に着地してしまう。問いの立て方は答えを決定するわけではないが、答えの探索範囲を強く方向づける。そして現状、この翻訳は仕組みではなく、担当者個人の力量か偶然に任されてしまっている。

この「脅威ごとの足し算」は、以下の3つの帰結を生むと考える：

1. 第一に、対策の全体像が「脅威と対策の対応表」になり、表の行を埋めた時点で完了した気になってしまう。個々の対策が製品か設定か訓練かに関わらず、対策同士の整合性や、それらを支える土台（資産管理、復旧力など）の有無は問われない。
2. 第二に、責任が脅威に最も近いセキュリティ部門とベンダーに局所化され、経営・業務部門・一般の従業員にとってセキュリティは「自分の問題ではない」ものになる。
3. 第三に、脅威は無限に更新され続けるため、足し算も無限に続く。新しい脅威が報じられるたびに対応表に行が増え、予算と人の疲弊を生む。冒頭の「対策一覧がツール一覧になる」現象は、この足し算の力学に、製品の形で答えを供給する市場の力学が重なった、最も目に見える症状である。

実例：「VPNは危険だ」という言説

身近な例がVPNを巡る言説である。ランサムウェア被害の報道でVPNが侵入経路として言及されることが増え、「VPNは危険だ。脱VPN・ゼロトラスト移行を」という言説が広まった。脅威（VPN経由の侵入）を主語にした瞬間、答えは「VPNを捨ててZTNA/SASE製品を買う」という製品の置き換えになってしまう。

しかし、以前のブログ（「VPN利用の現状と脱VPNの現実性について」）において、「SaaSセキュリティリーグ」での実務者による議論が示す現実は、もっと複雑である。VPNの利用は、従業員のリモートアクセス・サードベンダー用アクセス・拠点間アクセスという用途ごとに事情が異なる。SIPの制約でVPNを残さざるを得ない領域があり、SASEのコストの問題があり、パートナーからVPN接続を求められれば運用での統制で対応するしかない場面もある。

つまり実務の答えは「製品の総入れ替え」ではない。自組織のアクセス経路を棚卸しして把握し、リスクの高い経路から優先的に手を打ち、技術で解決できない部分は運用で統制することである。さらに言えば、VPNが侵入経路となった事故の多くで実際に効いてくるのは、VPNという技術の存在そのものではなく、パッチ未適用の機器や多要素認証の不在、棚卸しされていないアカウント、つまり基本対策の穴である。

「VPNは危険だ」という脅威の語りは、この現実をすべて覆い隠し、「どの製品に乗り換えるか」という問いだけを残してしまうことになる。

注意：　断っておきたいこと

誤解のないように、これは現場のセキュリティ担当者への批判ではない。脅威ごとの足し算を続けさせてきたのは、脅威の深刻さでしか動かない予算プロセスであり、恐怖を喚起することが最も効率的な営業手段になっているセキュリティ市場の構造であり、さらに遡れば「情報セキュリティとはCIAを維持すること」という定義の構造である。この定義が歴史的にどう成立したかはともかく、CIAは結果として、攻撃者が情報に対してできること（見る・変える・使えなくする）に対応している。そのため、この定義のもとでは、関心が自然と「侵害が有るか無いか」に向かいやすい（この対応関係と、CIAを目的ではなく評価軸として捉え直す考察は、以前のブログ「ゼロトラストとCIA（前編）」「同（後編）」を参照）。

現場は、この構造の中で最善を尽くしてきた。問題は人ではなく、語りの構造にある。だからこそ、語りの構造を変えることに意味があると考える。

第2章. 捉え直し：セキュリティとは「コントロール可能にすること」

では、脅威の代わりに何を主語に置くべきか。

以前のブログ「ゼロトラストとCIA（後編）」は、情報セキュリティの目的を「コントロール可能にすること」、すなわち何が起きても、把握し・対処し・戻れる状態を保ち続けることと再定義することを提案した。CIAは目的ではなく、その状態を評価するための軸である。

この捉え直しの実践的な意味は、問いが変わることにある。「この脅威をどう防ぐか」ではなく、「何が起きても、我々は把握し、対処し、戻れるか」である。前者の答えは脅威ごとに積み上がる個別対策となるが、後者の答えは脅威を横断して効く組織の能力となる。資産を把握しているか。侵害の影響を限定できる設計になっているか。何日で事業を戻せるかを自分たちで決められているか。何が起きたかを後から説明できるか。これらは特定の脅威のための対策ではなく、どんな脅威に対しても効く土台であり、その大半は技術製品ではなく組織の営みである。脅威は無限に増えるが、保つべき能力は有限である。足し算が無限に続く世界から、有限の土台を育てる世界への転換と言うこともできる。

実例：Mythosレディの正しい読み方

この捉え直しが机上の空論でないことを示すのが、いま最も「脅威論」を煽りやすい題材、すなわちAIによる攻撃能力の問題であると考える。

2026年4月のClaude Mythos Previewの登場は、AIが脆弱性発見からexploit生成までを機械速度で実行しうることを示し、大きな衝撃を与えた。恐怖で語ろうと思えば、いくらでも語れる題材である。そして脅威論で受け取った組織は、「Mythosにどう対抗するか」「Mythos対策製品はどれか」という問いを立てるであろう。

しかし、「AI脆弱性の嵐」を解説したブログ「Mythosレディとは何か」は、まさにこの読み方を明確に退けている。Mythosレディとは「すごいハッキングツールに対抗する体制」のことではない。すなわち、脅威論として捉えるべきではない、と言っている。実際、各社モデルの能力は急速に収束しており、「Mythosだけを管理すればよい」という特定脅威への対応は、すでに現実から離れつつある。特定の脅威に紐づけた対策は、脅威が一般化した瞬間に意味を失う。脅威を主語にしたアプローチの賞味期限は、それほど短いと考えられる。

注目すべきは、この最先端の脅威に対して同文書が示した処方箋である。それは新しいAI防御製品の導入ではなく、まず取り組むべきは、資産管理、ネットワークセグメンテーション、パッチ管理の継続化、IAM、多層防御の再設計という基本対策の強化であり、その目的は「コントロール可能な状態の実現」である。高度な攻撃への対策より、基本の穴を塞ぐことが先決である。攻撃者は最も弱い点を狙う。

ただし、ここで言う基本対策は「一度整備すれば終わり」のものではない。ブログ「Mythosレディとは何か」の続編-2「VulnOpsとCTEM：継続的脆弱性管理の具体的な実装」が示すように、脆弱性の発見から武器化までの猶予が数時間レベルに縮むと言われている環境では、「スキャンしてパッチを当て、次のスキャンを待つ」という定期イベント型の運用は、その前提から崩れてしまう。だからこそこのブログでは、脆弱性の発見・優先順位付け・修復を常時回し続けるVulnOpsとCTEM、すなわち基本対策の継続的な運用化をMythosレディの中核に据えている。

機械速度のAI攻撃という、史上最も恐ろしげな脅威ですら、行き着く答えは新奇な対抗製品ではない。基本対策を、環境の変化速度に合わせて回し続け、コントロール可能な状態を「保ち続ける」ことなのである。

第3章. 基本対策は「地味な義務」ではなく「コントロール能力の部品」である

脅威を主語にした世界では、基本対策は分が悪い。脅威は常に「新しいもの」として報じられるが、資産管理もパッチ適用もバックアップも何十年も変わらず、ニュース性がなく、ベンダーが売り込む目玉にもならない。結果、最新製品が積み上がる横で、足元の基本が穴だらけになる。そして実際のインシデントの多くは、高度な攻撃ではなく、その基本の穴から起きている。

しかし「コントロール可能にすること」を目的に置くことで、基本対策の位置づけが一変する。基本対策とは、組織のコントロール能力を構成する部品そのものである。

• 資産管理・ログ収集は「把握する」能力の実体である。何を持っているか知らずにコントロールはできない
• アクセス制御・最小権限・MFAは「対処する」能力の実体である。侵害が起きたとき、攻撃者が動ける範囲を最初から狭めておく営みである
• バックアップと復旧訓練は「戻れる」能力の実体である
• 監査ログの保全・記録は「説明できる」能力の実体である
• パッチ適用と脆弱性管理の継続運用は「適応し続ける」能力の実体である。VulnOps/CTEMは、この能力を機械速度の環境に対応させた実装形態にほかならない

高度な製品は、この基本の上に載る追加部品にすぎない。たとえば、資産台帳のない組織にEDRを入れても、アラートが指す先が分からなければ対処できないということが起こりうる。

第4章. 実践：問いを入れ替える

実践の核心は、新しい施策の追加ではない。意思決定の起点に置く問いを、入れ替えることである。第1章で見たように、脅威の問いから組織的な答えに至るには問いの「翻訳」が必要であり、それは現状、個人の力量か偶然に任されている。ならば、翻訳を偶然に任せず、最初から翻訳後の問いを置くようにしたい。つまり、「この脅威をどう防ぐか」をやめ、「何が起きても、我々は把握し、対処し、戻れるか」と問うことである。これは、抽象論ではない。セキュリティ担当者が日常的に立てる問い（あるいは経営や他部門から投げかけられる問い）に、そのまま当てはめることができるものである。以下に、そのいくつかの例をあげる：

場面	よくある問い	新たに入れ替えた問い
重大な脆弱性が公表された	CVSSスコアが高い。対応すべきか。	この脆弱性は自社のどこに存在するか、それにすぐに答えられるか。実際の悪用は始まっているか。塞ぐまでの間、悪用に気づく手段はあるか。
他社の大きな被害が報道された	うちの会社は同じ攻撃を防げるか。	同じことがうちの会社で起きたら、何時間で気づき、何日で事業を戻せるか。
ベンダーから製品提案を受けた	この製品はどの脅威を防げるか。	この製品は我々のどの能力を高めるか。それを活かす土台（資産管理など）は整っているか。
インシデントの振り返り	なぜ防げなかったのか。誰のミスか。	検知・対処・復旧のどこで時間を失ったか。次は、もっと早く気づき、早く戻れるか。
新システムの導入審査	セキュリティ要件のチェックリストを満たしているか。	このシステムで事故が起きたとき、気づけるか（ログ）、影響を限定できるか（権限）、戻せるか（バックアップ）。
経営への報告・予算要求	今月の脅威動向はこの通り。この脅威への対策費がほしい。	検知から対処までの時間は縮んだか。元の状態に戻すのに、いくら投資するか。
従業員への注意喚起	怪しいメールを開かせないために、どう注意喚起するか。	異変に気づいた従業員が、責められずに、すぐ報告できるようになっているか。

以上のように、入れ替えの規則は単純である。よくある問いの主語は「脅威」や「製品」であるが、入れ替えた問いの主語はすべて「我々」であり、問うている中身は、第3章で挙げた能力——把握する、対処する、戻れる、説明できる、適応し続ける——のいずれかである。会議において問いが脅威や製品を主語にし始めたと気づいたら、「それは、我々のどの能力の話か」と置き直すことが重要である。それだけで、議論は製品の比較から、自組織の足りない土台の話に戻ってくると考えられる。

この問いの入れ替えは、特に経営との対話で効いてくると考えられる。脅威ベースの予算要求では、経営は投資の効果を確かめようがない。それは、攻撃が起きなかった場合、それが投資のおかげなのか、単に運が良かっただけなのかを、区別できないからである。効果が測れない以上、出すか出さないかの判断のよりどころは「どれだけ怖いか」しかなくなってしまう。したがって、恐怖が薄れれば予算は削られ、「昨年対策したのに、なぜ今年もまた要るのか」という問いに答えられなくなる。

これに対し、能力を問う形の予算要求では、投資の前後で数値化が可能になる。検知から対処までの時間がどれだけ縮んだか。復旧訓練で目標時間内に事業を戻せたか。資産の把握率がどれだけ上がったか。効果が測れれば、経営は他の事業投資と同じ物差しでセキュリティを評価し、判断できる。また、能力は放置すれば劣化するものだから、継続的に投資が必要な理由も自然に説明がつく。基本対策の地味な工数に予算と権限がつかないことに悩んでいる現場にとって、これは武器になるはずである。

なお、基本対策が進まない理由の多くは、現場の問題ではなく組織的な障壁である。パッチを当てたくても、古い基幹システムは業務への影響が大きくて止められず、停止する日程について関係部門の合意が取れない。資産の管理責任者が誰なのか分からない。業務部門の協力が得られない。これらは技術では解決できず、経営層の関与によってしか解決できない。NIST CSF 2.0がGovern機能を独立した柱に据えたのは、この認識の表れであると考える。だからこそ、経営に通じる問いへの入れ替えは、現場の自助努力の話ではなく、構造を動かすための要件なのである。

おわりに：脅威とは、天気予報のように付き合えばよい

最後に、誤解のないように以下の2つの点を補足しておきたい。

第一に、本ブログは「脅威を無視してよい」と言っているのではない。台風が近づいていると知れば、私たちは怖がって騒ぐのではなく、雨戸を閉め、ベランダの物を固定し、停電に備える。台風の情報は、人を怖がらせるためのものではなく、備えるためのものである。脅威の情報も同じように扱うべきであると考える。実際、現場では既にそうしている。脅威インテリジェンスを検知に活かすことや、実際に悪用されている脆弱性（KEV）から優先的にパッチを当てる判断は、まさに「備えるための情報利用」であり、「把握する」能力の一部である。本ブログが見直したいとしているのは、人を怖がらせて動かすための脅威の使い方であって、こうした実務まで否定するものではない。

第二に、「コントロール可能にすること」は、新しいバズワードでも、新しい製品カテゴリでもない。NIST CSF、Assume Breach（侵害を前提とする）、レジリエンスといった、現場がすでに知っている考え方を、一つの目的としてまとめ直したものである。この捉え直しのために、新しく製品を買うというようなものではない。

現場のセキュリティ担当者であれば、本ブログの内容の多くは、すでに肌で感じていることだと思う。防御製品を並べても侵害は起き、勝負を分けるのは把握と復旧であることを、インシデントを経験した人ほど知っている。足りていなかったのは知識ではなく、それを組織に通すための問いの立て方だったのではないだろうか。「この脅威をどう防ぐか」ではなく、「何が起きても、把握し、対処し、戻れるか」。この問いから始めることが重要と考える。

以上