スタンダードプランの対応方針の検討

FutureVulsを使用すると、検出された脆弱性に対して、柔軟にトリアージ（受容するものの選別や優先度付け）が可能です。このページでは、スタンダードプランにおけるトリアージ方針やFutureVuls上での脆弱性の取り扱いについて説明しています。

実際の画面上での作業は、次のページで実施します。

本チュートリアルでは、以下の利用者を想定しています。

以下の利用者環境を想定しています。 高度な機能を持つ環境の場合は、適宜、方針に従った運用をして下さい。

• 担当者は少なく、緊急度の高いものをなるべく早く選別したい。
• インターネットへの公開サーバを想定しており、一旦はローカルからの攻撃については除外して考える。
  • サーバへのログイン監査やログ監査を行っているため、内部のログインユーザの悪意有る行動は把握できる想定。
  • ネットワークアクセスからのローカル権限昇格を用いた攻撃などは、ネットワークアクセスの攻撃を防ぐことで、一旦は緩和できるとする方針。

方針

多数の脆弱性の対応順位付けをするために、以下のように対処していきます。

• 対応するリスクについて検討する
  • 受容できるもの/できないもの、の判断基準を明確にする
  • 各脆弱性について、受容できるかを検討する
• 受容する脆弱性を、除外する
  • FutureVuls上で、非表示にする
• 受容できない脆弱性を、対応緊急度に応じて優先度をつけ、対応する
  • アップデート等の対応をする

上記の各フェーズに対して検討します。

対応するリスクについて検討する

脆弱性により発生する「リスク」に対して、検討します。

• 発生するリスクに対して、以下の対処が可能かを検討します。
  • 軽減：発生頻度や影響度を減らす対策。不正なWEBアクセスに対して、WAFで防御するなど。
  • 回避：発生頻度がなくなるような対策。不使用サービスのアンインストールなど。
  • 転嫁：影響や責任を、別の対象に移す対策。ハードウェア故障に対して、所有からSaaSサービスへの移行など。
  • 受容：対策をせず、影響を受け入れる。ローカルの権限昇格の脆弱性について、ログインできない前提で受容するなど。
• これらのどれにも当てはまらないものについて、対応が必要になります。
  • 影響を軽減や回避や転嫁できず、受け入れられないものを対象とする。

軽減/回避/転嫁/受容できるかを検討し、対応対象から除外します。

• 軽減
  • 例えば、WAFのシグネチャ追加により防御する、などを行えるかを検討します。
  • あくまで軽減であり、完全に対策がされるわけではないことに注意が必要です。
• 回避
  • 例えば、対象の「脆弱性の有るサービス」を止められるか、別の同様のサービスに移行できるか、などを検討します。
  • また、アップデートを行う、という選択肢も含まれます。
  • 通常、アップデート以外の選択肢を取るのは難しいと考えられます。（例えば、BINDからPowerDNSへ移行する、など）
• 「受容するリスク」を決定する
  • 例えば、攻撃はローカルからしかできないもの（CVSS VectorのAVがA,L,Pなど）は前提条件が有るので受容する、などを検討します。
  • システムが配置されている場所や、軽減や回避ができるもの、という観点でも受容可能なものを検討します。
  • どこからの攻撃か（インターネット側のみ、内部ネットワークも含む、等）、軽減や回避が可能か、発生する影響はどのようなものか（DoSによるサービス停止は受容できるがデータの漏洩や改ざんは許されない、等）などの、「システムが置かれている社会的環境」を元に受容できる範囲を決定します。

受容する脆弱性を除外する

受容するリスクは、以下が想定可能です。

• アップデートパッチが提供されていないもの
  • 且つ、緩和策が無い場合は、対処の方法がありません。この場合は、パッケージを削除するか、対応可能となった場合に再度検討します。
  • パッチ提供:☓、緩和策/回避策:☓ → 非表示（脆弱性情報に対して何らかの変更があるまで）
• ネットワーク経由の攻撃ができないもの
  • ローカルで発現する脆弱性（権限昇格やバッファオーバーフロー）などは、別の対策により緩和できている=リスク低減できている、という場合があります。
  • その際は、「攻撃区分がローカルのものは受容する」という選択肢があります。
  • NWから攻撃可能: ☓ →非表示（脆弱性情報に対して何らかの変更が有るまで）
• 回避や軽減が可能なもの
  • 軽減については、「設定変更により影響を受けなくなる」ものが含まれます
• 発現する影響の検討
  • 可用性を重視しないシステムであれば、DoSが発生する脆弱性は受容できる可能性があります。
  • 一般的には、リモートでのコード実行（RCE）などは無視できない可能性があります。

受容できるもののうち「直接対応しないもの」を、FutureVuls上で除外（非表示）にします。

• 現在表示されている脆弱性を「更新がされるまでは対応しない」ものとして扱います。
  • 時折、CVSS VectorやBaseScoreが更新されることがあり、その際は再検討します。
  • 例えば、パッチ未提供やネットワークからの攻撃以外のものについて、一括で非表示にします。
• 回避や軽減が可能なものについては、対応が終わった段階で、タスクを「WORKAROUND」に変更します。
  • 回避軽減により、リスクを受容できる状態にしたことを記録します。

受容できない脆弱性を、対応緊急度に応じて優先度をつけ、対応する

受容できない脆弱性について、個別に対応を検討します。 CVSSのスコアだけではなく、複数の指標から対策優先度を決定し、順次対応していきます。

• 以下の項目を参考に、対策優先度を決定します。

  • NWから攻撃可能
  • 緩和策/回避策 なし
  • 攻撃コードあり
  • 権限無しで攻撃可能
  • 警戒情報 あり

• 重要視する順番の一例を示します。

  1. 警戒情報は、攻撃の可能性が高い場合や影響度が高い場合に、JPCERT/CCなどから公開されます。
  2. NWから攻撃可能は、インターネット側からのアクセスで攻撃される可能性が高くなります。
  3. 攻撃コードありは、公開されたコードを元に攻撃される可能性が高くなります。
  4. 緩和策/回避策なし及び権限無しで攻撃可能は、攻撃の容易さに影響します。

• 一例として、以下の優先順位で対応を決定します。

  1. CVSS v3/v2 または Red Hat のスコア順に表示する
  2. 警戒情報 あり、 攻撃コード あり、 緩和策/回避策 なし
  3. 警戒情報 あり、 攻撃コード あり
     • 既に攻撃用のコードが公開されており、CISA-KEVCやJPCERT/CC等からの警戒報告が出ているものは、すぐにでも攻撃が始まる（既に始まっている）可能性が高いため最優先で対応する
  4. NWから攻撃可能 、 攻撃コードあり
  5. NWから攻撃可能

優先度が決定できた後、適用について検討します。

• すぐに適用が可能なのか
  • 検証が必要であれば、ステージングでの検証の計画が必要です。
  • 優先度が低い場合、優先度が高いものと同時に対応するか、別途定期アップデートなどで適用するのかの計画が必要です。
• アップデートを行う場合、どのバージョンにするのか
  • 基本的には最新版にするのが望ましいです。他の脆弱性も同時に解決される場合が多いです。
  • また、今後更新版が公開される場合、1つ前のバージョンからの動作確認をして提供されることが多いです。その為、なるべく新しいものにしておくことで、動作確認を一部省略可能と考えられます。

備考

以上、大まかな対処フローを記載しましたが、組織のポリシーや運用ポリシーにより、適切ではない場合があります。 以下のような対応も検討が必要です。

• パッチ提供:☓、緩和策/回避策:☓　の環境でも、攻撃コードあり:○　の場合、注意が必要です。
  • 攻撃コードは有るが防御策がない、といった場合があります。
  • しかしながら、「悪用はできない事を確認したため、インパクトは低いと考えられる」、「将来のアップデートでこの問題に対処する予定である」という対応がされている場合もあります。（バックポートを利用している、RHELなどで散見されます）
  • 脆弱性ハンドリングのリソースが潤沢であればここまで確認したほうが良いですが、そうでない場合、一旦はベンダ判断を以てリスク受容とするのも良いです。

FutureVulsでの注意点

• 対応の抜け漏れ確認は 脆弱性 タブの 未対応 を利用します。
  • ステータスが NEW 且つ 非表示ではない もの = 検知後に対応していないものが表示されます。
• サーバ毎に判断する必要の有る脆弱性は、脆弱性 タブではなく、サーバ タブ、 ロール タブ、 タスク タブで確認をします。
  • 公開サーバであれば無視してよいが、内部サーバでは無視できない、といった判断の必要な場合があります。
  • その際は サーバ タブ、 ロール タブ、 タスク タブで対象のCVE-IDを指定し、サーバ毎に非表示設定やステータス変更の必要があります。