サイバーセキュリティの積み残し課題は、セキュリティ部門の問題ではない

サイバーセキュリティチームが担うべきは、あらゆる是正措置を自ら実行することではなく、リスクを監督する役割です。発見、優先順位付け、担当割り当て、実装、追跡、検証というすべての是正作業をセキュリティチームに背負わせてしまうと、責任の所在はかえって曖昧になります。その結果、セキュリティチームは未解決課題の単なる「保管庫」と化してしまうのです。

より効果的なモデルでは、役割を明確に分けます。セキュリティは監督役に徹し、実際の是正作業はテクノロジー部門とビジネス運用部門が担うという分担です。セキュリティが維持すべきは、信頼できるリスク一覧です。そこから優先順位を定め、是正の基準を設け、対応が遅れている案件をエスカレーションし、対応完了を検証します。一方、影響を受けるインフラ、クラウド環境、アプリケーション、ID基盤、あるいは業務プロセスの所有者が、実際の修正を実行する責任を負います。そして経営層は、リソースの競合を解消し、組織として対応しないと判断したリスクを明示的に受け入れる役割を担います。

この線引きは些細なことではありません。脆弱性管理プログラムが実際にリスクを低減できるか、それとも単に是正チケットを量産するだけに終わるかは、この分担にかかっているのです。

積み残し課題の増加は、運用モデルの失敗を示す兆候

セキュリティチームは、「セキュリティ上の懸念」というラベルが付いたあらゆる問題のデフォルトの担当者にされがちです。たとえば、スキャナーが古いパッケージを検出すれば、サーバーのパッチ適用はセキュリティチームの仕事だとみなされます。クラウドセキュリティプラットフォームが公開状態のストレージバケットを検知すれば、デプロイ構成の見直しもセキュリティチームの役目とされます。同様に、監査で業務アプリケーションの過剰な権限が発覚すれば、その業務フローを担当する部門とのアクセス変更交渉も、セキュリティチームが行うことになりがちです。

こうした構図が生まれるのは、問題の「発見」は目に見えやすい一方で、「是正」はしばしば都合の悪い作業だからです。セキュリティチームが報告書をまとめると、組織はその解決策の実行もセキュリティチームの責任だと思い込んでしまいます。時間が経つにつれ、インフラ、エンジニアリング、ビジネス部門の担当者たちは、チケットの起票、対応手順の提示、会議の設定、期限の管理、例外申請、経営層への遅延報告まで、すべてセキュリティチームがやってくれるものと期待するようになります。結果として、本来は主体的に取り組むべき当事者であるはずのシステム所有者が、単なる一参加者の立場に追いやられてしまうのです。

その結果生じる積み残し課題は、しばしばセキュリティチームの責任とされます。ダッシュボードを管理しているのがセキュリティチームだからです。しかし、そのダッシュボードが示しているのは、実はより根深い組織的な機能不全にほかなりません。資産に対する所有権が誰にも割り当てられていない、是正作業が業務のキャパシティに組み込まれていない、そして信頼性や製品リリース、顧客対応、技術的負債といった優先事項をリスク低減のためにいつ後回しにすべきかについて、経営層が明確な意思決定権限を確立してこなかった――そうした失敗の表れなのです。

NISTのサイバーセキュリティフレームワーク2.0は、組織全体でサイバーセキュリティリスクをガバナンスし、優先順位付けし、周知することの重要性を強調しています。セキュリティ部門自らがすべての是正措置を実行すべきだとは推奨していません。同様に、NISTのエンタープライズパッチ管理ガイダンスも、パッチ適用は予防保守であり通常の事業コストの一種であるとし、セキュリティチームだけが担う特殊業務とは位置付けていません。

積み残し課題とは、単に技術的な弱点を寄せ集めたリストではありません。それは、未解決の組織的な意思決定の記録です。放置期間が長くなっている項目一つひとつが、次のような未回答の問いを映し出しています。このシステムを所有しているのは誰か。変更を実行する権限を持つのは誰か。考慮すべき事業への影響は何か。利用可能なリソースはどれだけあるか。残存リスクを受け入れる権限を持つのは誰か。

セキュリティはリスク記録の維持を担い、システム所有者は是正の実行に責任を負う

責任の所在を保つ最も効果的な方法は、新たな検出事項が見つかる前に、あらかじめ役割分担を定義しておくことです。

セキュリティが所有すべきは、既知リスクに関する信頼できる一覧です。具体的には、検出結果の妥当性確認、重複や誤検知の除去、技術的弱点と影響を受ける資産・業務サービスとの紐付け、リスクベースの優先順位付け、是正の最低限のエビデンス基準の策定、対応遅延案件のエスカレーション、そして対応完了の独立検証が含まれます。またセキュリティは、パターンの識別も担うべきです。ほぼ同一のクラウド設定ミスが10件見つかった場合、それは10件の無関係なチケットではなく、デプロイ基準の欠陥、自動化の欠如、あるいは予防的統制の弱さを示す証拠なのです。

優先順位付けは、単純な深刻度スコアリングにとどまるべきではありません。米サイバーセキュリティ・インフラセキュリティ庁(CISA)は、脆弱性管理の優先順位付けの材料として既知の悪用脆弱性(KEV)カタログの活用を推奨しています。これは実際に悪用された証拠がある脆弱性を明示しているためです。たとえば、隔離されたテスト用資産にある深刻度の高い脆弱性よりも、インターネットに公開されており特権アクセスに関連し、実際に悪用されている、スコアの低い弱点の方が緊急対応を要する場合があります。脅威と統制の双方の文脈を包括的に把握しているセキュリティチームこそが、こうした判断を下すのに最も適した立場にあります。

是正措置の実行は、該当するテクノロジーやプロセスを所有するチームの責任とすべきです。インフラチームはサーバーやエンドポイントのパッチ適用や再設定を担当します。クラウドプラットフォームチームはID、ネットワーク、ストレージ、ログ管理の統制に対応します。アプリケーションチームは依存関係を更新し、脆弱なコードを再設計します。そして業務システムの所有者は、ワークフローやアクセス変更を承認します。これらのチームは、依存関係やテスト要件、停止リスク、業務への影響について必要な理解を持っており、かつ恒久的な解決策に必要なエンジニアリング上の仕組みをコントロールする立場にあります。

経営層が担うのは、セキュリティチームにもシステム所有者にも解決できない意思決定です。是正のコミットメントが製品リリース、顧客対応、信頼性への懸念、あるいは予算制約と衝突する場合、それはすでに経営判断の領域に入っています。リソースを追加投入するのか、期限を変更するのか、代替統制を承認するのか、あるいはリスクを受け入れるのか――こうした選択は経営層が下さなければなりません。沈黙はリスク受容を意味しません。あらゆるチームがより緊急性の高い業務を抱えているという理由だけで検出事項が放置され続けることは、責任ある意思決定が伴わない「管理されていないリスク」にほかなりません。このモデルはまた、評価指標そのものの再定義も促します。セキュリティチームは、カバレッジ、検証速度、優先順位付けの質、エスカレーションの迅速さ、対応完了の検証精度によって評価されるべきです。是正の担当者は、リスク低減の度合い、優先度の高い検出事項の放置期間、再発率、自動化や恒久的な設計変更によって解消できた作業の割合によって評価されるべきです。そして経営層は、利用可能なリソースに対する積み残し課題の増加ペース、未解決のリソース競合、期限切れとなった例外措置、そして資金の裏付けのある対応計画を伴わないまま受け入れられたリスクの量を監視すべきです

いかなる組織機能も、自らの権限が及ばない業務について責任を問われるべきではありません。

積み残し課題の解消に必要なのはキャパシティの増強であり、SLAの追加ではない

多くの組織は、積み残し課題の増加に対して、より厳格なサービスレベル合意(SLA)の導入で対応しようとします。たとえば「深刻度の高い検出事項は15日以内に、優先度の高い検出事項は30日以内に対応する」といった具合です。しかし、方針を変更しダッシュボード上の緊急度表示を強めたとしても、実際の是正キャパシティそのものは変わらないままであることが少なくありません。

SLAはあくまで「コミットメント」であって、「労働力」ではありません。CSOの最近の記事も同様の指摘をしています。パッチ適用のSLAは戦略ではなく最低ラインとして位置付けるべきだというものです。なぜなら、緑色に彩られたコンプライアンス達成率の指標は、本当に重要な少数の困難なリスクを覆い隠してしまう可能性があるからです。期限が意味を持つのは、担当チームがそれを満たすための権限、スキル、メンテナンスウィンドウ、テスト環境、エンジニアリングのための時間を実際に持っている場合に限られます。

この問題は、組織が多大な技術的負債を抱えている場合に、特に深刻になります。数千件に及ぶ旧来の脆弱性、サポート切れのシステム、クラウド設定ミス、ID関連の弱点、監査指摘事項を、すでに日々の運用や戦略的取り組みに手一杯なエンジニアリングチームにそのまま割り振っても、実効性のある是正計画にはなりません。過負荷状態にあるチームが、積み残し課題の重要性だけを理由に追加のキャパシティを生み出せることはまずないでしょう。

一定の規模に達した組織は、過去から積み上がったリスク負債を解消し、持続可能な運用ペースを確立するための専任の一時的な是正チームにリソースを割り当てるべきです。このチームは期間を限定し、独立した予算を持ち、インフラ、クラウド、アプリケーション、自動化、プログラムマネジメントの専門知識を備えた人材で構成することで、単なる調整役ではなく、実際に変更を実行できる体制とすべきです。セキュリティは、優先順位付けと独立検証の責任を維持すべきであり、是正作業の主たる実行部隊になるべきではありません。

この一時的な是正チームが取り組むべきは、個々のチケットではなく、問題のカテゴリー単位です。その責務には、自動パッチ適用や構成のベースライン策定、サポート切れコンポーネントの置き換え、再利用されるインフラテンプレートの修正、放置された資産の除去、エビデンス収集の標準化、そして繰り返し例外を認めるのではなく経営判断を要するシステムの洗い出しが含まれます。サイバーセキュリティリスク、エンタープライズリスクマネジメント、人員計画を結び付けたNISTの2026年ガイダンスは、リスク対応と人員配置の意思決定を連動させるべきだという原則を裏付けています。

このチームの発動基準は、検出件数の恣意的な数値であってはならず、むしろ新たに発生するリスクと是正キャパシティとの間の持続的な不均衡を基準とすべきです。その兆候としては、積み残し課題が継続的に増加していること、通常の変更サイクルを超える高リスクの検出事項が存在すること、弱点が繰り返し発生していること、あるいは是正作業に既存キャパシティの数四半期分を要することなどが挙げられます。こうした状況は、通常の運用体制ではプログラムを立て直すのに不十分であることを、経営層に示す証拠となります。

終了基準は明確に定めておく必要があります。過去から積み上がった高リスクの積み残し課題を解消すること、残存作業を通常チームが対応可能な水準まで減らすこと、繰り返し発生する修正作業を自動化すること、各資産に責任を持つ所有者を割り当てること、そして新たに発生する優先度の高いリスクが、発生するペースよりも速く解消されるという測定可能なペースを確立することです。

サイバーセキュリティの積み残し課題は、セキュリティチームの失敗を意味するものではありません。むしろそれは、リスクを特定する権限と、それに対応するためのキャパシティおよび責任とが、組織の中で切り離されてしまっていることを物語っています。

セキュリティが担うべきは、リスクの監視、検証、優先順位付け、エスカレーション、そして対応完了の検証です。システム所有者は是正措置を実行し、経営層は戦略的な意思決定を下すべきです。これらの責任分担が明示的に定義され、適切にリソースを配分されない限り、どれだけ多くのスキャナー、チケット、ダッシュボード、SLAを導入しても、積み残し課題が解消されることはないでしょう。