リソース · 23
脆弱性の優先順位付けと修復の検証
既知の悪用、露出した資産、ビジネスへの影響、および修正が機能していることの証明を関連付ける。
更新済み · 3 min
このガイドが達成するのに役立つこと
- アラートをアセットに照合する
- 実際の緊急度をランク付けする
- 安全に展開する
- 検証して完了する
クイックチェック
- 影響を受ける製品とバージョンは実際に展開されているか？
- アセットにアクセス可能で、ビジネス上重要なものか？
- 悪用事例は文書化されているか？
- パッチ適用前にサービスを保護するものは何か？
- チェックによって、アセットから問題が解消されたことが確認されているか？
手順
- 1
インベントリを統合する
サービス、製品、バージョン、環境、露出、所有者をマッピングする。 コンポーネントアドバイザリだけでは、脆弱なインスタンスが展開されていることを証明できない。
成果物：日付付きの影響を受けるアセットリストと不確実性。
- 2
発見事項の検証
ベンダーのアドバイザリ、CVE識別子、悪用条件、および該当する場合はCISAの既知の悪用された脆弱性カタログを比較します。 各情報源を確認した日時を記録します。
成果物：主要な参照資料を含む発見事項。
- 3
妥当な優先順位の設定
既知の悪用、資産へのアクセス可能性、必要な権限、処理されるデータ、サービスへの影響、および利用可能な修復策を考慮します。 担当者と状況に応じた期限を設定します。
成果物：理由を付した優先順位決定。
- 4
変更の準備
依存関係、変更ウィンドウ、バックアップ、およびロールバックをマッピングします。 更新を速やかに適用できない場合は、一時的な制御とその有効期限を記録します。
成果物：ロールアウト計画と限定的な例外。
- 5
展開とテスト
承認されたプロセスを使用して、ベンダーの修正プログラムまたは緩和策を適用します。 結果として生じるバージョン、業務プロセス、および後退する可能性のある統合を確認してください。
成果物：デプロイメント記録と機能結果。
- 6
クローズの確認
適切な方法で実際のアセットを確認し、見落としたインスタンスを特定し、例外を再検討してください。 更新がスケジュールされただけという理由でチケットをクローズしないでください。
成果物：検証証拠と更新された登録簿。
管理指標
| 指標 | 測定対象 | 最初のアクション |
|---|---|---|
| 網羅性 | バージョンと所有者が既知の重要資産 | インベントリの完了 |
| 遅延 | 認定から検証済み修正までの時間 | 繰り返し発生するボトルネックの解消 |
| 検証 | 実際の資産で修正を再テスト | 証拠なしにクローズを再開 |
| 例外 | 管理、所有者、有効期限付きの免除 | 期限切れの例外をクローズ |
よくある間違い
- 資産を確認せずに一般的なスコアのみでランキング付け
- KEVリストに掲載されているということは、製品が自社環境に存在することを意味すると想定する
- サービス動作をテストせずに展開する
- レビュー日を設定せずに補償制御を放置する
よくある質問
スコアが最も高いCVEを常に最初に処理する必要があるか？
スコアは技術的な深刻度を表します。 既知の悪用、露出、ローカルサービスへの影響に基づいて運用順序を決定します。
パッチが存在しない場合はどうすればよいか？
ベンダーの緩和策に従い、可能な限りリスクを低減し、担当者、レビュー日、および残存リスクを文書化する。
作業はいつ完了するのか？
影響を受けるインスタンスでバージョンまたは緩和策が検証され、重要な機能がテストされた後。
公式参照文献
参照文献はメソッドを裏付けるものです。 チェックは状況に合わせて調整してください。 これらは認証ではありません。 元の参照文献のタイトルやソース文書は別の言語で書かれている場合があります。
