スタンダードプランでの使い方#

ここでは、 FutureVuls スタンダードプランのユーザが脆弱性トリアージをする上での基本的な考え方と、実際に画面操作を通じた対応手順について説明します。なお、CSIRTプランでは高度な自動トリアージ機能が使えるので、そちらをご参照ください。

FutureVulsを使用すると、検出された脆弱性に対して柔軟なトリアージ（受容するものの選別や優先度付け）が可能です。

受容可能な脆弱性を「非表示」にする
受容できない脆弱性に優先順位をつける

組織によって受容基準は異なりますが、ここでは比較的緩やかなトリアージの例として、以下の脆弱性を受容するとします。

攻撃元区分がネットワーク以外
パッチが提供されていない
攻撃に権限が必要

本チュートリアルの想定利用者

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

担当者は少なく、緊急度の高いものから選別したい
インターネットへの公開サーバを想定しており、ローカルからの攻撃は一旦除外する
- サーバへのログイン監査やログ監査を行っており、内部のログインユーザによる悪意ある行動は把握可能
- ネットワークアクセスからのローカル権限昇格を用いた攻撃などは、ネットワークアクセス対策で緩和可能

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

手順	対応内容	対応実施
1	対応するリスクの検討	・「受容できるもの/できないもの」の判断基準を明確にする・各脆弱性について、受容できるかを検討する
2	受容する脆弱性の除外	FutureVuls上で非表示にする
3	受容できない脆弱性への対応	アップデート等の対応をする

対応するリスクの検討#

脆弱性により発生する「リスク」に対して検討します。発生するリスクに対して、以下の対処が可能かを検討します。いずれにも当てはまらないものについて、対応が必要になります。

対処分類	対処内容	具体例	注意
軽減	発生頻度や影響度を減らす	不正なWEBアクセスに対してWAFで防御する	あくまで軽減であり、完全な対策ではない
回避	発生頻度をなくす	・該当のサービスの停止/アンインストール・別サービスへの移行・アップデートの実施	通常、アップデート以外の選択肢を取るのは難しいことが多い（例えば、BINDからPowerDNSへ移行するなど）
転嫁	影響や責任を、別の対象に移す	ハードウェア故障を、所有からSaaSサービスへ移行
受容	対策をせず、影響を受け入れる	・ローカルの権限昇格の脆弱性はログインできない前提で受容する	どこからの攻撃か（インターネット側のみ、内部ネットワークも含む、等）、軽減や回避が可能か、発生する影響はどのようなものか（DoSによるサービス停止は受容できるがデータの漏洩や改ざんは許されない、等）などの、「システムが置かれている社会的環境」を元に受容できる範囲を決定

受容する脆弱性の除外#

以下の脆弱性は受容可能と考えられます。

対策	説明
アップデートパッチおよび緩和策がないもの	対処の方法がないため、パッケージを削除するか、対応可能となった場合に再度検討する
ネットワーク経由の攻撃ができないもの	ローカルで発現する脆弱性（権限昇格やバッファオーバーフロー）などは、別の対策により緩和できている（=リスク低減できている）
発現する影響の検討	・可用性を重視しないシステムであれば、DoSが発生する脆弱性は受容できる可能性がある・一般的には、リモートでのコード実行（RCE）などは無視できない可能性がある

これらを FutureVuls の画面上で非表示にします。

アップデートパッチおよび緩和策がないもの#

該当のパッケージを削除しない場合、このソフトウェアの脆弱性には現時点では対応できません。

そこで、パッチや緩和策が公開されるまで FutureVuls 上で表示しないように設定します。

フィルタで「パッチ提供：×」および「緩和策/回避策：×」を設定
該当脆弱性を一括選択し、「関連するタスクを非表示」を選択
「脆弱性情報に対して何らかの変更があるまで」を選択し、非表示設定

ネットワーク経由で攻撃できないもの#

ローカルで発現する脆弱性（権限昇格やバッファオーバーフロー）などは、別の対策により緩和できている（=リスク低減できている）、という場合があります。その際は、「攻撃区分がローカルのものは受容する」という選択肢も取ることはできます。

フィルタで「NWから攻撃可能：×」を設定
該当脆弱性を一括選択し、非表示設定

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

受容可能な脆弱性を非表示にし、対応不要なものを除外します。回避・軽減可能なものは、対応後にタスクを WORKAROUND に変更します。

受容できない脆弱性への対応#

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

優先度の決定#

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

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

重要視する順番の一例

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

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

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

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

適用計画#

すぐに適用が可能なのか、検証が必要かを判断します。

検証が必要であれば、検証環境を準備して行う計画が必要です
優先度が低い場合、優先度が高いものと同時に対応するか、別途定期アップデートなどで適用するのかを計画します

また、アップデートする場合、どのバージョンにするのかを判断します。基本的には最新版にするのが望ましいです。これにより、他の脆弱性も同時に解決される場合が多いです。また、今後更新版が公開される場合、1つ前のバージョンからの動作確認をして提供されることが多いです。その為、なるべく新しいものにしておくことで、動作確認を一部省略可能と考えられます。

注意#

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

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

FutureVulsを利用する上でのタブの推奨#

対応の抜け漏れ確認は 脆弱性 タブの 未対応 を利用します。ここには、ステータスが NEW 且つ 非表示ではない もの（= 検知後に対応していないもの）が表示されます。

また、サーバ毎に判断する必要のある脆弱性は、脆弱性 タブではなく、サーバ タブ、 ロール タブ、 タスク タブで確認をします。

公開サーバであれば無視してよいが、内部サーバでは無視できない、といった判断が必要な場合があります。その際は サーバ タブ、 ロール タブ、 タスク タブで対象のCVE-IDを指定し、サーバ毎に非表示設定やステータス変更の必要があります。

実際の画面操作#

受容できる脆弱性を非表示にする#

攻撃元区分が「ネットワーク」以外のものを、非表示にします。

このセクションでは、画面操作方法の説明のために攻撃元区分が「ネットワーク以外」のものを非表示にしていますが、攻撃元区分が「ネットワーク以外」の脆弱性はすべてリスクが低いわけではないことに注意してください。

「脆弱性」の「NWから攻撃可能：×」でフィルタ
該当脆弱性をチェックし、「関連するタスクを非表示」を選択
「脆弱性情報に対して何らかの変更があるまで」を選択し、送信

select_tasks

ignore_tasks

同様に、パッチ提供がないものを非表示にします。

組織のポリシーに応じて、「警戒情報：○」「攻撃コードあり：○」「緩和策/回避策：☓」「権限無しで攻撃可能：○」、などでフィルタしていく場合もあります。

リスクを受容できるものを画面上で非表示にする事で、対応しなければいけない脆弱性のみ画面に表示させます。

「CSIRTプラン」の「自動非表示機能」を用いると事前にリスクを許容するルールを定義してタスクの自動非表示が可能です。サーバタグと組み合わせることで柔軟に定義可能です。

例えば、以下のような脆弱性はリスクが低いとみなして自動で非表示にする、といったことが可能となります。

「社内システム」タグがつけられているサーバ
ネットワークから攻撃されない

受容できない脆弱性に対応する#

前述の「受容できるものを非表示にする」をした後は、対応が必要な脆弱性のみが残ります。残っている脆弱性に対して、優先順位を決めて対応していきます。

優先順位は、基本的には CVSS v3 の BaseScore の順で見ていきます。 v3 の情報がない場合は、v2 のスコアを参照します。 Red Hat Enterprise Linuxの場合は Red Hatのスコアを優先的に参照します（バックポート等の考慮が有るため）。

スコアが高いものから順に、その他の指標を見ながら判断します。例えば、スコアが9.5 以上のグループに対して、「警戒情報/攻撃コード/回避緩和策なし/権限無しで攻撃可能」の項目が有効な場合、優先的に対応することとします。脆弱性の詳細を開くと、サマリやCVSSベクタから「どのような影響が及ぼされるのか」がわかります。例えば、「遠隔でのコード実行は優先的に対応する」「可用性に影響が有るだけであれば、少し優先度は落とす」などの判断が可能です。

cvss_vector

上記のような情報から優先順位を付け、優先度に従って対応していきます。

画面の項目の入れ替え

列の項目は入れ替えることができるため、例えば RHEL のサーバのみの環境であれば、下記の順番でカラムを設定すると良いでしょう。

Red Hat（RedHatが提供する、スコア）
CVSS v3/v2のスコア
サマリ
攻撃コードあり
警戒情報
NWから攻撃可能
権限無しで攻撃可能

緩和策で対応する#

対象のタスクの左側チェックを入れ、「関連するタスクを更新」を押します。これから対応する場合は「タスクステータス」を ONGOING に設定し、担当者に連絡します。緩和策で対応完了後は、タスクのステータスを WORKAROUND にします。 WORKAROUND 状態になったタスクは、「未対応」には表示されなくなり「対応済み」に表示されます。

パッチ適用等で対応する#

これから対応する場合、「関連するタスクの更新」で「タスクステータス」を ONGOING にします。

パッチ適用で対応する場合は、適用完了時にステータスを変える必要はありません。対応完了後のスキャンで、自動的にタスクステータスが PATCH_APPLIED に変わり、脆弱性一覧から消えます。

また、脆弱性対応時は FutureVuls のパッチ適用をサポートする機能をお使い下さい。

パッチ提供済みのタスクでは、「アップデートコマンド」ボタンを押下すると選択したサーバ上で発行するアップデート用のコマンドが表示されます（マニュアル）
「タスク」タブでタスクを選択し、「ANSIBLE PLAYBOOK」ボタンを押下するとAnsibleのPlaybookをダウンロード可能です（マニュアル）
AWS連携を設定するとFutureVuls上で実際にパッケージをアップデートできます。「タスク」タブでアップデート対象のタスクを選択し、「SSMアップデート」ボタンを押下してください（マニュアル）

対応完了後の確認#

脆弱性への対応完了後、脆弱性一覧から当該脆弱性が表示されなくなっていることを確認します。

タスクステータスが WORKAROUND や PATCH_APPLIED となると非表示になります
リスクを受容した脆弱性も、非表示としておきます
以降、未対応の脆弱性を定期的に、同様に処理していく必要があります

オーガニゼーション内の他の運用者に情報共有、注意喚起する#

「トピック機能」を用いると、同じオーガニゼーションの他グループの運用者に情報共有ができます。オーガニゼーションやグループ内で CVE-ID 単位の情報共有を行えるため、Slackでの情報共有やメールと比較して情報が一箇所に集約、蓄積されます。

このグループではアップデート対応した
アップデートしようとしたが、テストで API 非互換の問題が出た
インターネット上で攻撃が多発しているので注意が必要

など、有益な情報を組織内で情報共有しましょう。