「脆弱性管理をちゃんとやれ」と経営層やCSIRTから求められたものの、具体的に何をどう進めればいいのかわからない──そんな悩みを抱えていませんか。本記事では、脆弱性管理の基本的な考え方と、Taniumを使った「発見→評価→対処→検証」の実践ワークフローを解説します。
目次
- 「脆弱性管理をやれ」── でも、何をすればいいの？
- そもそも脆弱性管理とは何をすることなのか
- なぜ「パッチを当てるだけ」では不十分なのか
- Taniumで回す脆弱性管理の型 ── 発見→評価→対処→検証
- 現場で回すための運用設計のポイント
- まず何から始めるか ── 最初の3ステップ
「脆弱性管理をやれ」── でも、何をすればいいの？
「脆弱性管理を強化しろ」「ちゃんと回せ」──経営層やCSIRTからそう言われたものの、具体的な指示があるわけではない。パッチは一応当てているし、Windows Updateも回している。でも、それで本当に十分なのだろうか。
こうした悩みを抱えている情シスの方は、決して少なくありません。多くの企業で「脆弱性管理をやらないといけないとは思っているけれど、何をしていいのかわからない」「どこから手をつけていいのかわからない」という声を耳にします。
「パッチを当てていれば脆弱性管理はしなくていいんじゃないの？」──そう思っている方も多いのですが、実はそれだけでは不十分です。
実際、サイバー攻撃の99.6%は既知の脆弱性を悪用したものだと言われています。つまり「対処すべき脆弱性」は明確に存在しているのです。さらに、日本企業のパッチ適用にかかる平均日数は36.4日と世界で最も長いという調査結果もあります（トレンドマイクロ、2025年）。この時間差こそが、攻撃者にとっての狙い目です。
「何かやっている」ことと「管理できている」ことの間には、大きなギャップがあります。まずはこのギャップを正しく理解するところから始めましょう。
そもそも脆弱性管理とは何をすることなのか
脆弱性管理を一言で表すなら、「限られたリソースで効果的にセキュリティリスクを下げるための戦略を立て、実行すること」です。
すべてのパッチが適用され、アプリケーションは適切に更新され、利用が禁止されたアプリケーションは削除され、端末の設定も理想的な状態になっている──それが理想ではありますが、そのような状態を作り、保ち続けるには多大な労力がかかり、現実的には不可能に近いでしょう。
だからこそ必要なのが「脆弱性管理」です。各端末にどのような脆弱性があるのかを把握し、それぞれの脆弱性の深刻度を見極め、対策の優先度を決める。どこから手を付ければいいのかを判断し、時にはリスクを許容する。そういった戦略を立てるための材料を提供するのが脆弱性管理の本質的な役割なのです。
具体的には、以下の4つのステップを継続的に回します。
- 発見: 自社環境にどんな脆弱性があるかを把握する
- 評価: どの脆弱性から対処すべきか、優先度を決める
- 対処: パッチ適用・ソフトウェア更新・設定変更を実施する
- 検証: 対処が完了したかを確認し、次のサイクルへつなげる
これは1回やって終わりではなく、継続的に回すサイクルです。多くの組織が「発見」まではできていても、その先の「評価→対処→検証」が回っていないのが実情です。
なぜ「パッチを当てるだけ」では不十分なのか
WSUSやIntuneでWindows Updateを回している──それ自体は重要な取り組みです。しかし、OSのパッチだけでは守りきれない領域が存在します。
OSパッチだけではカバーしきれない
WindowsであればMicrosoftが毎月リリースする月例パッチを適用すれば、最低限のOS脆弱性には対応できます。しかしLinuxの場合、用途や導入されているパッケージが環境によって大きく異なるため、「毎月決まったパッチを当てる」という画一的な運用が成り立ちません。環境ごとに必要なパッチを見極める必要があるのです。
ライブラリ・OSSの脆弱性は見えない
2021年末に世界中を騒がせたLog4jの脆弱性を覚えているでしょうか。このようなオープンソースソフトウェア（OSS）やライブラリの脆弱性は、OSのパッチでは修復されません。そもそも「自社環境のどこにLog4jが使われているのか」を把握すること自体が困難です。ソフトウェアの「部品」に潜む脆弱性は、通常のパッチ管理の対象外であり、別の手段で可視化する必要があります。
サードパーティアプリは多岐にわたる
ブラウザ、PDFリーダー、圧縮ツール、開発ツールなど、業務で使用するサードパーティアプリケーションにも脆弱性は存在します。これらはWindows Updateの対象外であり、ベンダーごとに個別のアップデートが必要です。業務で利用するアプリケーションは多岐にわたるため、そのすべてを常に最新に保ち続けることは容易ではありません。
設定の脆弱性はパッチでは潰せない
端末やアプリケーションがデフォルト設定のまま運用されていると、それ自体がセキュリティリスクになります。パスワードポリシーの不備、不要なサービスの有効化、暗号化設定の不足などです。これらの設定上の脆弱性は、いくらパッチを適用しても解消されません。CIS Benchmarkなどの基準に照らして、設定の逸脱を継続的にチェックする仕組みが必要です。
つまり、「パッチ管理」は脆弱性管理の重要な一部ではありますが、それだけでは全体をカバーできないのです。
Taniumで回す脆弱性管理の型 ── 発見→評価→対処→検証
ここからは、Taniumの4つのモジュールを組み合わせた具体的なワークフローを解説します。
発見 ── Comply + SBOM で脆弱性を洗い出す
ワークフローの起点は「発見」です。まずTanium Complyで、OS・アプリケーションのCVE脆弱性をスキャンします。さらにTanium SBOMでソフトウェアコンポーネントを一覧化したうえで、Complyでの脆弱性スキャンを行います。この2つを組み合わせることで、「どの端末にどういった脆弱性があるのか」を網羅的に把握できます。
OSやアプリケーションの既知の脆弱性はComplyだけでも検出できますが、SBOMを組み合わせることで、通常のスキャンでは見つけられないOSSやライブラリの脆弱性まで可視化できるのがポイントです。
ここで、脆弱性管理で頻出する用語を整理しておきます。
| 用語 | 正式名称 | 説明 |
|---|---|---|
| CVE | Common Vulnerabilities and Exposures | 脆弱性を一意に識別するための共通番号（例: CVE-2021-44228）。脆弱性管理の基本単位 |
| CVSS | Common Vulnerability Scoring System | 脆弱性の深刻度を0.0〜10.0で数値化するスコアリング基準。スコアが高いほど深刻 |
| KEV | Known Exploited Vulnerabilities | 米国CISAが公開する「実際に悪用が確認された脆弱性」のカタログ。対処の緊急性が高い |
| EPSS | Exploit Prediction Scoring System | 脆弱性が今後30日以内に悪用される確率を予測するスコア（0〜1）。CVSSの深刻度に加え「実際に悪用される可能性」で優先度を判断できる |
評価 ── 見つける前に「基準」を決めておく
脆弱性を洗い出した後、すべてに対処するのは現実的ではありません。だからこそ「トリアージ」──対処の優先順位付けが重要になります。
ここで大切なのは、脆弱性を見つけてから基準を考えるのではなく、見つける前にどういった基準を設けておくのかを決めておくことです。
たとえば、以下のような基準をあらかじめ設定します。
- CVSSスコアが最上位の脆弱性: 強制パッチ適用、強制アンインストール、利用停止措置を取る
- 中程度のスコアの脆弱性: 是正勧告を出し、期限内の対応を求める
- 低スコアの脆弱性: リスクを許容する（対応しない判断を明示的に行う）
さらに、CVSSスコアだけでなく複数の指標を組み合わせることで、より実態に即した優先順位付けが可能になります。KEVに掲載されている脆弱性は実際に悪用が確認されているため最優先で対処すべきですし、EPSSのスコアが高い脆弱性は今後悪用される可能性が高いと予測されるため、CVSSスコアが中程度であっても優先度を引き上げる判断ができます。
Complyの「Remediation Visibility」機能を使えば、検出された脆弱性から修復アクションへ直接つなげることも可能です。
対処 ── Patch + Deploy + Enforce で修復を実行する
評価に基づいて優先度が決まったら、実際の修復に移ります。対処の手段はパッチ適用だけではありません。脆弱性の種類に応じて、適切なモジュールを使い分けます。
- Tanium Patch: OSパッチの展開を担当します。Confidence Scores（成功率・クラッシュ頻度）の情報が提供されるため、パッチ適用による業務影響のリスクを事前に把握したうえで展開できます
- Tanium Deploy: サードパーティアプリケーションの更新・入れ替えに加え、脆弱性のあるアプリケーションのアンインストールも実施できます。パッチが提供されていないソフトウェアへの対処手段として重要です
- Tanium Enforce: アプリケーションの利用制限や、端末設定の是正を担当します。パッチでは対処できない「設定の脆弱性」に対して、あるべき設定を強制適用することでリスクを低減します
このように、脆弱性の種類に応じて「パッチを当てる」「アプリを更新・削除する」「設定を是正する」「利用を制限する」と対処手段を使い分けるのが、脆弱性管理における対処の基本的な考え方です。
検証 ── 継続的な監視で修復状況を確認する
Complyでの脆弱性スキャンは基本的に定期実行するため、対処後に改めてスキャンを走らせるというよりも、日々の定期スキャンの中で修復状況が継続的にモニタリングされるイメージです。「パッチを配信した」だけでなく、次回のスキャン結果で「脆弱性が実際に消えたのか」が確認されます。
修復率はダッシュボードで可視化でき、経営層への報告にもそのまま活用できます。「何件の脆弱性を検出し、何件を修復し、現在の残存リスクはどの程度か」──こうした数字で語れるようになることは、経営層とのコミュニケーションにおいても大きな意味を持ちます。
現場で回すための運用設計のポイント
ワークフローの全体像は理解できたとしても、「5人のチームで本当に回せるのか」という不安は残るでしょう。ここでは、限られたリソースで脆弱性管理を定着させるためのポイントを整理します。
リスク評価基準を先に決める
運用を始める前に、まずリスク評価の基準を明確にしておきましょう。侵害された場合の影響、侵害の可能性、脆弱性スコアの3軸で判断基準を作り、「この条件に該当したらこう対応する」というルールを定めておきます。属人的な判断に頼ると、担当者が変わったときにワークフローが止まります。
今あるリソースで対応可能なスコープを決める
すべての脆弱性に対応しようとすると、すぐにリソースが枯渇します。今あるリソースを最大限効果的に機能させることが大切です。対応可能な範囲と優先度を決め、その範囲内で確実にサイクルを回すことを目指しましょう。
経営層との認識合わせ
経営層に状況を共有して、経営層が望む基準とそれを満たすために必要なリソースや時間を合わせる──これも非常に大切なポイントです。「ここまでのリスク低減を実現するにはこれだけのリソースが必要」という形で対話することで、現場の負荷を適正化し、投資対効果の理解も得やすくなります。KPIとしては、脆弱性検出数、平均修復時間（MTTP: Mean Time To Patch）、修復完了率、KEV対応率などが経営報告に適しています。
まず何から始めるか ── 最初の3ステップ
「全部一気に始められない。最初の一歩は何か」──その問いに対する答えをまとめます。
Step 1: リスク評価基準を決める
脆弱性を見つける前に、見つけた後の対応基準を決めておきましょう。CVSSスコア、KEVへの掲載有無、EPSSによる悪用可能性、自社環境への影響度などを軸に、「即時対応」「期限付き対応」「許容」の3段階程度で分類するのがシンプルで始めやすい方法です。
Step 2: Complyで脆弱性スキャンを定期実行する
まだ定期スキャンを実施していない場合は、ここから始めます。まずは月次でスキャンを回し、自社環境の脆弱性の全体像を把握しましょう。頻度は運用が安定してから段階的に上げていけば十分です。
Step 3: Patchで重大脆弱性のパッチ適用を始める
評価基準で「即時対応」と判断された脆弱性から、Patch、Deploy、Enforceを活用して修復を開始します。対象を絞って確実に対処し、修復率を可視化することが重要です。
大切なのは、小さく始めて着実にサイクルを回すことです。
自社環境に合った脆弱性管理ワークフローの設計や、Taniumモジュールの活用方法についてご相談がありましたら、お気軽にお問い合わせください。