FutureVuls Blog

組織カテゴリ

脆弱性管理は“組織改革”から──ツール任せにしない運用の秘訣

本記事では、SANS Instituteの講師であるDavid Hazar氏がYouTube動画で解説した「脆弱性管理の真の秘訣」についてまとめます。
脆弱性管理ツールや優先度付けなどの一般的な施策だけでは解決できない課題を、どのように組織横断で取り組むべきかが詳しく語られているため、セキュリティ担当者の方はぜひ参考にしてみてください。

  • 対象: 企業のセキュリティ担当者
  • ポイント:
    1. なぜ、単なるツール導入や一部施策で不十分なのか
    2. どうやって組織全体を動かすのか

“秘訣”は何か？──Better Technology Management

  • プレゼンターのDavid Hazar氏は20年以上のセキュリティ経験・SANS講師として、非常に多くの企業での脆弱性管理事例を見てきた。
  • そこから抽出した共通点が、「単なるツール導入や一部施策でなく、組織全体のテクノロジー管理（Better Technology Management）が鍵である」というメッセージ。
  • 動画3:08でいよいよ「The Secret to Vulnerability Management」が明かされる。
  • それは「Better Technology Management（より良いテクノロジー管理）」。
  • さらに、“Security Incidents Don’t Hurt”という形で、組織を動かすにはインシデントが強力な後押しになるとも言及。
  • 「セキュリティインシデントが起きると経営層や現場の意識が一気に高まりやすい」ことを指摘しつつ、待ってはいけないが、有効に活用すべきタイミングだと強調されています。

脆弱性管理の重要要素と「なぜ秘訣ではないのか」

全アセットの可視化

  • 組織内の資産（アセット）を正確に把握することは脆弱性管理の第一歩。
  • ただし、単に「把握した」だけでは根本解決にはつながらない。
Why it’s important Why it’s not the secret
把握できていないサーバやアプリが後から次々と発見されると、
脆弱性の総数や修正率などの報告が毎回大きく変わってしまう。

資産をきちんとリストアップしておけば、
脆弱性の変化を正しく追跡・管理しやすくなる。

特に、
「総脆弱性数」と「資産の数」を別々の指標として示す
か、もしくは1台あたりの脆弱性件数のような
相対的なメトリクスを併用することで、
資産が増えた結果の“見かけ上の脆弱性数増加”と、
実際のセキュリティ状況を
誤解なく伝えることができる。
(9:00付近)		 資産の存在を知るだけではパッチ適用や設定変更が自動的に進まない。
自動化ツール導入後も根本的な組織体制や予算が伴わねば意味がない。

脆弱性を全て洗い出す

  • どの脆弱性が潜んでいるかを把握しないと修正もできない。
  • ただし、洗い出しただけでは根本原因（レガシーコードの改修不能など）が解消しない限り意味がない。
Why it’s important Why it’s not the secret
全ての脆弱性を把握すれば、リスク評価やチームへの説得材料になる。
アプリ固有のビジネスロジックもできる限り洗い出しが必要。
(11:01付近)		 発見した脆弱性を修正するには追加のリソースや根本的な組織改革が必須。
優先度をつけても、改修工数やアーキテクチャ上の制限で
すぐに対応できないケースが多い。
例えば、
- レガシーOSをアップグレードすると大規模テストが必要
- 古いフレームワークで根本的なコード改修が必須
- 規制承認手続きが非常に重い
などで先延ばしになりがち。

アプリ固有のビジネスロジック洗い出しとは？
一般的なミドルウェアやOSの脆弱性とは別に、アプリ独自の権限管理や業務フロー、処理ロジックが原因となる脆弱性を把握することを指します。自動スキャンだけでは検知しづらいため、アプリ仕様の確認や手動テストが重要です。
例えば、特定のユーザしかアクセスできないはずの情報が権限管理の不備で見られてしまう、想定外の入力値で不正操作ができる、ワークフロー上の承認プロセスを迂回できるなど、組織のビジネスに直結する問題が潜んでいるかもしれません。
これらを発見できないままだと、システムの根幹を揺るがす重大なリスクになり得るため、洗い出しが必要です。

優先度付けと最も重大な脆弱性への集中

  • 大量の脆弱性を前にしたとき、有効なのが「CriticalやExploitが存在するものにフォーカスする」という考え方。
  • ただし、従来のCVSSスコアだけに基づく優先度付けでは十分に絞り込めないケースもあるので、より高度なトリアージ手法が有効。
Why it’s important Why it’s not the secret
膨大な脆弱性を一度に直すのは無理。
まず影響度が高いものから着手するとリスク低減効率が良い。
(17:16付近)

加えて、SSVC（Stakeholder-Specific Vulnerability Categorization）などの手法を用いると、
ビジネス影響やシステム重要度を踏まえて
よりきめ細かく優先度を決められるため、
「Criticalだけれど影響の少ない脆弱性」や
「Exploitはないが業務的にリスクが高い脆弱性」も
見逃しづらくなる。		 優先度付けだけでは、根本的な組織改革や
アーキテクチャの刷新が伴わない場合、
大きくバックログを削減するのは難しい。

脆弱性が一時的に減っても、
また新たな問題が次々に増えてしまう可能性があるため、
“継続的に”取り組む仕組みが必要。

具体例

  • 講演者が支援した企業で「10万件や100万件どころか、約1,000万件の脆弱性を抱えていた」といったケースが報告されています（19:02付近）。
  • 根本要因を取り除かない限り、数を減らしても新しい脆弱性が次々に増加し、いたちごっこになる。

用語：SSVC (Stakeholder-Specific Vulnerability Categorization)
CVSSなどの汎用的な指標だけでなく、ビジネス影響度や悪用可能性、システム重要度などを組み合わせ、より細かく優先順位を付けるための手法。
大量の脆弱性を抱える場合でも、組織独自の要件に合わせて危険度を再評価し、修正対象を効果的に絞り込める。

脆弱性データを統合する

  • インフラ系スキャナ、アプリ系スキャナ、ペンテストなど、ソースが別々だと全体像を掴めない。
  • 統合は必要だが、それ自体が解決策ではない。
Why it’s important Why it’s not the secret
別々に出力される結果を一元管理できれば、
抜け漏れや重複の把握が容易になる。
(20:21付近)		 どれだけ可視化しても、「現場が修正に取り組める環境」がなければ前に進まない。
レポートだけ追加されると、むしろ疲弊する場合も。

新技術やツールの導入

  • 高機能な脆弱性管理ツールや自動化ソリューションは、運用をスケールさせるために重要。
  • とはいえ、「今のツールが悪いから乗り換えれば解決」という考え方は誤りになりやすい。
Why it’s important Why it’s not the secret
自動化や大規模対応を補う新技術は、
運用負荷を下げたり、機能不足を補ったりする。
(23:00付近)		 「入れ替えただけ」で利用定着しないと逆効果。
すでに優秀なツールがあっても運用していなかったなら、
新ツールでも同じ問題に陥る可能性が高い。

クラウド移行

  • デジタルトランスフォーメーションの好機として、アーキテクチャ刷新やプロセス改善を行いやすい。
  • しかし移行先の責任分界点を理解していなければ抜け漏れが発生するし、手軽に増設できる結果、むしろ管理対象が急増する場合も。
Why it’s important Why it’s not the secret
共有責任モデルでパッチ負担を減らすなど、
クラウドの強みを活かせる。
(26:00付近)		 ベンダー責任範囲を誤解すると、脆弱性が放置される。
サーバ増設が簡単になりすぎて管理対象が倍増し、
従来の問題がさらに拡大しかねない。

“Better Technology Management”が求められる理由

動画38:00頃から、どうして「ただの施策列挙では不十分なのか」を整理し、「Better Technology Management」がなぜ必要かを解説。
代表的な課題として、以下の5つが挙げられています（44:00付近）。

課題 内容
Legacy systems and software 古いアプリやOSが放置され、パッチや改修が非常に困難。
Cumbersome processes and methodologies 手続きや承認フローが重く、ちょっとした変更にも大きな負担がかかる。
Lack of or inconsistent use of automation 自動化できる部分（例: false positiveの除外など）を人力でやってしまい、対応が遅れる。
Lack of or inconsistent enforcement of standards 同じ組織内でもチームによって基準が異なり、セキュリティ格差が生まれる。
Insufficient resources or the wrong resources セキュリティ担当が兼任状態だったり、必要なスキルや人員を確保できず実作業が追いつかない。

ポイント: 脆弱性管理は問題を「見える化」する手段にはなるが、それ自体が課題を解決するわけではない。

Better Technology Managementとは？

脆弱性管理ツールやスキャンだけでは、「脆弱性を見つける」ことはできても、「直すための予算や人員を確保する」「変更承認をスムーズに進める」「レガシーを根本的に改修する」といった組織的・構造的な問題を解決するまでには至りません。
Better Technology Managementとは、こうした“脆弱性修正が遅れる要因”を抜本的に取り除くために、レガシー対応、ライフサイクル計画、組織体制、アーキテクチャ設計を包括的に見直し、発見した脆弱性を継続的かつ確実に修正できる状態を作る考え方を指します。
結果的に、この取り組みがあってこそ脆弱性管理ツールの導入効果が最大化され、継続的に安全な状態を維持できるようになるのです。

規制産業におけるパッチ適用のハードル

製薬業界などの規制産業では、システム変更＝再認証（再バリデーション）が必要になるケースがあるため、脆弱性修正をするだけでも大規模かつ煩雑な承認プロセスを経る必要が出てきます。
動画の41:01付近では、製薬業界で「パッチ適用するたびにシステムを再認証しなければならない」事例が紹介され、これが「レガシーシステムの放置」や「修正の先延ばし」につながる背景の1つになっていると解説されています。

第三者アウトソーシング時のKPI・契約の問題

外部ベンダーと脆弱性管理をアウトソース契約する場合、「毎月X％をパッチ適用する」などの抽象的KPIを設定すると、ベンダーが自動パッチで簡単に対応できる部分だけを満たし、
より困難な脆弱性は放置されるケースがあるとのことです（26:46～29:02付近）。
契約更新や再交渉のタイミングで、KPIを適切に修正しないと、結局“本当に手間がかかる部分”に対応されないというリスクが残ります。

30日ルール vs. リリースサイクル

たとえば「Criticalな脆弱性は30日以内に修正」というようなポリシーは一般的ですが、
四半期ごとにしかリリースできないチームの場合、常に期限切れの状態になるという問題が指摘されています（44:41付近）。
チームごとにリリース手法や運用スケジュールが異なるなら、一律のルールを適用するだけではなく、実効性のあるやり方を再考する必要があります。

組織全体を動かすための実践ポイント

ここでは、講演で語られた「どうやって組織全体を巻き込み、変革を進めるか」について、特に重要だった3つの視点をまとめます。

1. インシデントの活用──“Security Incidents Don’t Hurt”

  • 動画の3:23で示されているように、大きなインシデントは組織が本腰を入れるきっかけとして非常に有効。
  • “セキュリティインシデントが起きる前に”取り組むのが理想ですが、現実的にはインシデントが発生すると経営陣や現場が「他人事ではない」と痛感し、一気に予算やリソースが動きやすい。
  • ただし、インシデント後の一時的な盛り上がりだけで終わらないよう、日頃からリスクを定量的に示し、万一の際にも即座に動ける体制を整えておくことが大切です。

2. メトリクスの使い分け──トップ層と現場層

  • 経営層へのレポートに使う指標と、運用担当チーム向けの指標を意図的に変える・使い分けると、より効果的に組織を動かせます。
    • 例：経営層には「重大な脆弱性の推移」「ビジネスリスクに直結する事象数」など、インパクト重視のメトリクス。
    • 現場のエンジニアには「1台あたりの脆弱性件数」「優先度別の対応状況」など、具体的に動きやすいメトリクス。
  • 同じ数字でも、どの面を強調するかで人の動き方は大きく変わります。講演では、常に「この数値を見て、相手は何をどう変えるか」を意識し、定期的に表示する指標を調整するべきと語られていました。

3. トップダウンとボトムアップ──両方向からのアプローチ

  • 組織全体を動かすには、上層部の支援（トップダウン）だけでなく、実際のパッチや開発を担う現場の協力（ボトムアップ）も欠かせません。
  • 講演では「どちらか一方だけでは継続しない」と強調しており、例えば経営層が「セキュリティは優先度を上げろ」と言っても、現場が工数や予算を持っていなければ動けませんし、逆に現場が熱心でも経営の理解がなければ大きく改善は進まない。
  • そのために、セキュリティチャンピオンのような枠組みで現場のキーパーソンを育成したり、経営層には事業リスクや法規制などの観点で説得するなど、両面を意図的に狙うのが有効とされています。

用語：セキュリティチャンピオン
開発チームや運用チームの中で、セキュリティ分野に詳しく、他のメンバーにセキュリティの視点を広める「責任者」や「キーパーソン」を指す概念。
大規模組織や複数プロジェクトが並行する環境では、専門のセキュリティ部門だけでは全てをカバーしきれないため、現場チーム内に「セキュリティの理解者・推進役」を配置しておくことで、トップダウンとボトムアップの両方向から改善を進めやすくする狙いがある。

根本的な解決策──What Does Better Technology Management Look Like?

  • 組織によって異なるため“一律の方程式”はないが、動画44:00～53:00にかけて、いくつかの有効な方向性が示される。
  • 最終的なゴールは、単に“脆弱性を減らす”だけでなく、組織全体で継続的にリスクを許容範囲内に維持するしくみを確立すること。

1. 調達・ライフサイクル管理の見直し

  • レガシーシステムが生まれる原因の1つは、「最初だけ予算があり、保守や運用の予算が十分ではない」調達プロセスにある。
  • 今後のライフサイクル全体で予算確保・運用サポートを計画させる仕組みが重要。

用語：レガシーシステム
開発から長期間経過しており、技術的にも組織的にも更新や保守が困難になっているシステムのこと。具体的には、サポートが終了したOS・古い開発言語・廃止予定のフレームワークなどを使っているケースが多い。
新規の修正や機能追加を行うにも大規模な再設計が必要だったり、人材や予算が確保できずに放置されることが多く、脆弱性管理やセキュリティ対策の大きな障壁となる。

2. Immutableアーキテクチャを採用

  • コンテナやInfrastructure as Codeを使い、“変更”より“再デプロイ”で更新する発想。
  • ベースイメージを常に最新に保てば、セキュアな環境が自動的に再構築される。
  • 結果としてレガシー問題やパッチの適用漏れが大幅に減る。

用語：Infrastructure as Code (IaC)
手動作業で行いがちなサーバやネットワークの設定を、プログラムコードや宣言的ファイルとして定義・管理する手法。
例えば、クラウド上にサーバを建てる設定や、OSレベルのパッケージインストール、セキュリティ設定などをコード化し、バージョン管理や自動テストが可能となる。
組織的には「環境構築や設定変更を人任せにしないで、反復的かつ効率的に行える体制」を整えることになり、脆弱性修正やアーキテクチャ更新をスピーディーに進める効果がある。

3. PaaS/SaaS/Serverlessへの移行

  • 共有責任モデルを正しく理解し、ベンダー側が担う部分は任せることで自社の負荷を下げる。
  • ただし前述のとおり、どこまでがベンダー管理かを誤ると隙が生じる点に注意。

用語：PaaS / SaaS / Serverless

  • PaaS（Platform as a Service）: アプリケーションを開発・実行するためのプラットフォーム（OSやランタイム、ミドルウェアなど）をクラウド事業者が提供し、利用者は自分のコードに集中できるサービス形態。
  • SaaS（Software as a Service）: ソフトウェア自体をクラウド上で提供し、利用者はウェブブラウザやAPIを通じてそのサービスを使う形態。管理するのはユーザーアカウントや設定程度で、アプリのアップデートやサーバ運用はベンダーが行う。
  • Serverless（FaaS：Functions as a Serviceを含む）: 必要なタイミングで関数やコンテナを自動的に実行し、利用が終わればインフラリソースが解放される形態。サーバやOSの管理はほぼ不要で、コードに特化して開発できる。

共通点として、クラウド事業者が多くの管理・運用を担ってくれるため、利用企業はインフラレベルのパッチ適用やサーバメンテナンスの負担を減らせる。ただし、どの範囲までベンダーの責任で、どこから自社が責任を負うかを理解していないと、脆弱性管理にギャップが生じる可能性がある。

4. 使われていないアプリの廃止・置換

  • 利用実績の乏しいツールや重複機能を抱えたシステムを積極的に廃止し、管理対象を減らす。
  • Flash脆弱性の例（46:00付近）でも、根本は「古いブラウザしか動かないアプリの存在」だった。
    • 6か月間のプロジェクトで新しいブラウザ対応に改修し、一挙に数百万件規模の脆弱性が減ったという具体例が語られています。

      ポイント

      • “古いブラウザでしか動かない”という状況を放置すると、ブラウザ自体の脆弱性が膨れ上がり続ける。
      • しかしアプリを新ブラウザ対応にするには工数と期間が必要。
      • 組織としてプロジェクトを立ち上げ、6か月かけてでも根本的に改修した結果、膨大なFlash由来の脆弱性を一気に解消できた。
      • これはテクノロジー管理全体を見直して問題の根を断つ好例とも言える。

まとめ

動画全体を通じて、「脆弱性管理ツールやスキャンの網羅性だけでは問題は解消せず、“Better Technology Management”こそが鍵」というメッセージが一貫しています。
担当者視点では、次のような行動指針が考えられます。

  1. バックログに埋もれている脆弱性の根本原因を分析し、組織のプロセスやレガシーをどう改善するかを明確化する。
  2. 経営層や関連チームと協力し、調達・ライフサイクル管理・アーキテクチャ変更を進める。
  3. クラウド移行やツール導入は“推進力”になるが、準備不足のまま導入すると同じ課題を拡大しかねない。
  4. 不要なシステムを廃止・刷新する決断も検討し、可視化するだけでなく不要資産を積極的に減らす工夫を行う。
  5. インシデントやメトリクスの提示を機に、トップと現場の両方向に働きかける――継続的な体制が鍵になる。

当社（FutureVuls）でも、継続的な脆弱性管理を支援するSaaSとして、こうした組織全体の改善をサポートできるように取り組んでいます。

とはいえ、ツールがあればそれだけで解決するわけではないので、今回の動画が示す「Technology Management」の要点をぜひ踏まえてみてください。

脆弱性管理の導入コンサルティングメニューもございますのでぜひ、FutureVulsからお問い合わせください。

お問い合わせはこちら