脆弱性管理

読み：ぜいじゃくせいかんり　／　英語表記：Vulnerability Management

• セキュリティ
• 性能・監視・運用

情報システムの脆弱性を把握し、悪用の可能性や業務への影響から対処の優先順位を決め、対策と確認を継続的に行う管理活動である。診断による発見だけでなく、修正、緩和措置、例外の管理などを含む。

イマシルちゃんの解説

会社で使う機器やソフトに、攻撃に悪用される弱点である脆弱性が見つかったとするね。
でも一覧を作るだけでは、危ない状態は変わらないよ。
どの機器にその弱点があって、攻撃されたら何が困るのかを調べる必要があるんだ。
調査から対応順の判断、対策後の確認までをつなぐ管理活動が脆弱性管理だよ。
修正を入れるだけでなく、危険な機能を止めたり機器を入れ替えたりする場合もあるの。
使うソフトや見つかる弱点は変わるから、担当者を決めてこの作業を繰り返すんだ。
発見した情報を、実際に危険を減らす行動へつなげることが大切なんだね。

より深い解説

発見を、対策が終わるまでの活動につなぐ

脆弱性診断は弱点を見つけるための調査であり、セキュリティパッチの適用はその弱点を解消する手段の一つである。脆弱性管理は、それらを対象の把握、評価、担当者への割当て、対策、結果確認へつなぐ活動である。原因が不適切な設定であれば、プログラムの更新より設定の修正が必要になる場合もある。

一度診断して安全と判断したシステムでも、新しい弱点の公表や機器の追加によって状態は変わる。NIST SP 800-53 Rev. 5の管理策RA-5は、定期的な調査だけでなく、新たな脆弱性が判明したときの監視・調査と、その結果に基づく是正を扱っている。定期作業と新しい情報をきっかけにした作業の両方が必要である。

各段階の情報がつながっていなければ、診断報告はあっても担当者が決まらない、修正の依頼はあっても完了を確認できない、といった状態になる。検出件数を増やすことと、危険な状態を減らすことを同じ成果として扱わないようにする。

対象が見えなければ、見つからない弱点も増える

機器やソフトウェアの存在、構成、管理者などを把握する資産管理が調査の土台になる。サーバや利用者端末だけでなく、ルータ、VPN装置、クラウド上のサービス、コンテナ、組込み機器なども業務の構成要素である。管理対象の一覧と実際の環境を照合し、部署が独自に導入した機器などの抜けを探す。

記録するのは製品名と版だけではない。インターネットへ公開しているか、重要な情報へアクセスできるか、停止するとどの業務が止まるか、といった条件も必要である。同じ弱点でも、外部へ公開された認証基盤と、隔離された検証用端末とでは対応の緊急性が変わり得る。

部品を多数組み込んだソフトウェアでは、製品名だけから内部のライブラリまで判断できない。部品とその関係を記録するSBOMは、影響を受ける可能性のある製品を探す材料になる。ただし、一覧に部品があるという情報だけで、実際に攻撃が成立すると確定するわけではない。

複数の調査方法で、検出結果の意味を確かめる

ネットワーク越しの診断では、到達できるサービスや応答などから弱点を調べる。管理用の認証情報を使って内部のパッケージや設定を確認する方法は認証付きスキャンであり、外側からの応答だけでは分からない状態を調べるのに役立つ。権限が不足していたり認証に失敗していたりする場合は、実施済みの記録があっても必要な範囲を調査できていない。

このほか、ソフトウェア部品と公表情報の照合、設定の点検、ソースコードの解析などを使い分ける。外部からの診断は到達可能性を確かめるのに有効だが、内部のすべての部品を列挙できるとは限らない。調査の目的と取得できる証拠を対応付け、単一の手法で環境全体を確認できると考えないようにする。

診断はシステムに負荷を与える場合があるため、対象、実施時間、許容する検査内容を管理者と決める。特に古い機器や停止の影響が大きい設備では、検証済みの方法や提供元が認める方法を選ぶ。管理用の資格情報は必要な範囲に権限を絞り、診断のために防御設定を恒常的に弱めないようにする。

検出結果をそのまま確定情報にしない

実際には該当しない弱点を検出したと判断するのが誤検知である。例えば、上流の版番号が古くても提供元が修正を移植している製品では、文字列だけの判定が修正状況と食い違うことがある。Red Hatが説明する修正の移植方法も、版番号と修正の有無を単純に同一視できない例である。

逆に、実際に存在する弱点を検出できないことを見逃しという。対象が停止中であった、認証できなかった、調査用の情報が更新されていなかった、といった理由もあり得る。「検出がゼロ」と「必要な対象と検査項目をすべて確認できた」は別の状態である。

公表された脆弱性を共通の識別子で指す仕組みがCVEである。これは製品の危険度を表す点数ではなく、情報を突き合わせるための識別に用いる。実際の対象判定には、提供元のアドバイザリにある影響する版、設定、機能などの条件も照合する。未修正と判断した根拠と、対象外にした根拠の両方を残すと、後から条件が変わった際に判断を見直しやすい。

深刻度、悪用の実績、予測を読み分ける

技術的な深刻度を共通の方法で表す指標がCVSSである。特に基本評価値は、弱点の特性に基づく深刻度であり、そのまま自組織の損失や攻撃発生確率を表すものではない。v4.0では脅威や利用環境を反映する評価も用意されているため、「この仕組みは利用環境を一切扱わない」と理解するのも誤りである。FIRSTの評価ガイドは、基本評価値単独とリスク判断を区別している。

CISAが公表する、実際の悪用が確認された脆弱性のカタログがKEVである。掲載は現実の攻撃で使われたという判断材料になるが、その組織が既に侵害されたことまで示すわけではない。CISAの公式データを、対象製品と適用条件の確認に結び付けて利用する。

一方、公表済みの脆弱性が今後30日間に現実の攻撃で悪用される可能性を推定するのがEPSSである。予測値であり、特定の組織が侵害される確率でも、悪用済みであることの証明でもない。FIRSTの説明では、公開情報などに基づく推定値を日々更新している。

これらは異なる問いに答える情報である。点数の高いものだけを処理したり、予測値が低いという理由で確認済みの攻撃実績を無視したりすると、現実の危険を取り違える。

自組織で何が起きるかを加えて対応順を決める

ここでは判断のための架空例として、二つのシステムを考える。一つはインターネットへ公開したVPN装置で、使用中の機能に関する悪用が確認されている。もう一つは、より高い技術的な評価値の弱点があるものの、攻撃に必要な機能を無効化し、他の機器から隔離している検証用サーバである。

この条件なら、前者を先に対処する合理性がある。ただし「公開機器は常に最優先」「点数が低ければ放置してよい」と一般化するのは誤りである。管理者権限を持つ端末や認証情報を保存する内部サーバなども、侵入後の被害拡大につながる重要な資産である。

判断では、外部または侵害された内部端末からどのように到達するかという攻撃経路を確認する。そのうえで、必要な権限、利用中の機能、情報の重要性、停止の影響、既存の防御を組み合わせる。対応期限はこれらの条件から組織が定め、条件が変わったら同じ案件でも見直す。

修正、緩和、例外を区別して記録する

修正プログラムの適用、不適切な設定の変更、不要な機能や機器の撤去は、弱点の解消や攻撃可能な範囲の縮小につながる。直ちに修正できない場合は、接続元の限定やネットワークの分離などで危険を抑える。どの手段も、何を改善し、どの条件が残るかを具体的に記録する必要がある。

対策の後にも残る危険は残存リスクである。例えば外部からの接続を止めても、内部の端末からは問題の処理へ到達できる場合がある。この状態で、機器自体が修正済みになったと記録すると、制限の解除や構成変更によって危険が戻っても気付きにくい。

費用や業務上の理由で一定期間この危険を引き受ける判断をリスク受容という。単に未対応のまま放置することとは区別し、判断者、理由、適用範囲、有効期限、見直す条件を記録する。保守終了などにより修正を得られない場合は、代替製品への移行や廃止も対策計画に含める。

完了の証拠を残し、次の変化へ備える

対策担当者からの完了報告を受けたら、実際の版や設定を確認し、必要な範囲で再診断する。修正のインストールに成功しても、再起動待ちのまま古い処理が動いていれば完了とはいえない。設定で緩和した場合は、想定した経路が制限されていることと、必要な業務が動くことを確認する。

例外として残した案件や調査中の案件には、次に確認する条件と日付を設ける。新しい攻撃情報、構成変更、修正の公開などを受けて判断を見直す再評価が、古い判断を固定化しないために必要である。提供元が示すVEXという影響判断情報も参考になるが、その対象製品、版、前提条件が自組織の状態と一致するかを確認して用いる。

運用の評価には、未修正件数だけでなく、調査対象の網羅率、期限を超えた重大案件、対応に要した期間、長期間残る例外などを使う。廃止した機器を分母に残せば実態と指標がずれ、対象を十分に調べていなければ少ない件数が安全の証拠に見えてしまう。設計や運用の問題では、対象と根拠を確認し、誰がいつ何を行い、何をもって完了とするかまで説明できることが重要である。

この用語が出てくる記事

• CVSS
• セキュリティパッチ