脆弱性対策の基本は、ソフトウェアを常に最新の状態に保つこと。だが、これは理想であって、現実にはそう単純な話ではない。パッチはあてたほうがいいに決まっているが、何らかの理由で業務が止まれば現場からクレームが発生する。脆弱性対応の現場の切実な声が聞こえる。
●脆弱性管理に欠かせないリスク評価と CVSS スコア
公開された脆弱性情報をどう扱うか。ポイントはそのリスク評価にある。CVE に関連して CVSS(Common Vulnerability Scoring System)という危険度を表す指標が存在する。評価基準の見直しなども行われており(現在はバージョン4まで公開)、多くの企業や組織にとって、対応の自動化や対応の判定基準として役立っている。
注意点として、CVSS のスコア(危険度)は攻撃を受けた場合の影響度(インパクト)を示すもので、攻撃のしやすさ、発生頻度についての指標は含まれていない点が挙げられる。
攻撃のしやすさや成功確率の指標化は難しい。企業・組織、業種によってセキュリティ対策(=防御力)は一定ではないからだ。また、当然ながら使っていないソフトウェアのセキュリティパッチは実施する必要がない。また、パッチをあてることによって自社システムや業務に影響がないかどうかの見極めも必要になる。
この問題の正解は組織ごとにあり、ひとつではない。いわゆる銀の弾丸は存在しない。しかし、参考にすべき情報・知見・資料はある。そのひとつが日本シーサート協議会(NCA)が公開している「脆弱性管理の手引書 システム管理者編」である。2024 年 11 月に開催された Internet Week 2024 で、NCA 脆弱性管理 WG が、この手引書に沿った内容の講演を実施している。
本稿は Internet Week 2024 の NCA が登壇したセミナー「これは助かる!ありそうでなかった運用フレームワーク~脆弱性管理の手引き~」の取材メモから、とくにリスク評価の考え方についての解説を取り上げる。発表者は石田 悠 氏(NTT EWST-CIRT)、柴田 はるな 氏(NTT WEST-CIRT)、大石 眞央 氏(NTTDATA-CERT)である。
●対策プロセスの基本はシステムアセットの情報収集と脆弱性情報の把握
脆弱性管理は、まず社内・組織内のシステムについて情報を把握することから始まる。脆弱性を管理すべきシステムはどれか、それらの製品名、バージョン情報、機能、それらが保持している情報、インターネットからのアクセス可否、使用しているポート番号、設置場所、といった情報が基本となる。
以上のような情報が整理されていれば、公開される脆弱性情報について、対応するかどうかの判断が可能になる。組織の規模が一定以上になると、すべての情報を人力で集めて管理することは不可能だ。ネットワークスキャンやエージェントによる情報収集、アセット管理に頼ることになる。だが、手動管理や人間による確認も必要な部分も残るだろう。
講演では、脆弱性には「ソフトウェアの脆弱性」と「設定・設計の脆弱性」の 2 種類があるといい、本講演ではソフトウェアの脆弱性対応に焦点をあてるとした。設定の管理はポスチャマネジメントと呼ばれる領域の話であり、設計の脆弱性対策はセキュアコーディングや品質管理の話となる。