Inspector検出結果から対応優先度の高い脆弱性を抽出する

Security Hubになりたい山本拓海です。

稼働している環境でInspectorを有効化すると、大量の脆弱性が検出されて驚かれることもあるかと思います。 その際に、まずはどの脆弱性に対応が必要か、脆弱性の対応優先順を評価する手法を流用して優先順を検討したいと思います。

先に結論

SSVCの評価項目を流用した緊急性の高い脆弱性対応フィルターは以下の通りです。

• ワークフローのステータス = NEW or NOTIFIED
• レコードの状態 = ACTIVE
• 製品名 = Inspector
• ソフトウェアの脆弱性エクスプロイトが利用可能 = YES
• 重要度ラベル = CRITICAL or HIGH

ここに、AWSアカウントIDやVPC ID、インスタンスID、などで重要な環境、リソースのフィルターを追加してください。

前提条件

InspectorとSecurity Hubが連携していることを前提としています

CVSSのスコアとInspectorの重要度レベル

Inspectorの検出結果の重要度レベルは、基本レベルとしてCVSSのスコアが使用されます。 その他にEPSSスコアやInspectorが独自に採点するInspectorスコアなど複数の評価軸で脆弱性を評価し、最終的なスコアに応じて重要度のラベルをつけます。

スコアと重要度のラベルを抜粋します。

スコア	ラベル
9.0～10.0	CRITICAL
7.0～8.9	HIGH
4.0～6.9	MEDIUM
0.1～3.9	LOW
0	INFORMATIONAL

docs.aws.amazon.com

この重要度は、影響を受けたリソースが組織に対して緊急性または重要性を意味するものではありません。
そのため、脆弱性への対応の優先度は別の評価手法での検討が必要です。

SSVCで脆弱性対策への優先順位をつける

脆弱性対応の優先度として用いる評価手法としてSSVC（Stakeholder-Specific Vulnerability Categorization）という評価手法があり、 「政府機関等の対策基準策定のためのガイドライン」の資料でも紹介されております。 この評価手法をSecurity Hub上で検出結果をフィルターする条件に変換できないか考えてみました。

※ 政府機関等の対策基準策定のためのガイドライン（令和５年度版） https://www.nisc.go.jp/pdf/policy/general/guider5.pdf

※ CISA Stakeholder-Specific Vulnerability Categorization Guide https://www.cisa.gov/sites/default/files/publications/cisa-ssvc-guide%20508c.pdf

SSVCとはどういうものか

脆弱性を脆弱性の状態と脆弱性をはらむ環境に関する4つの評価基準で採点し、脆弱性対応の緊急性を採点するシステムで、アメリカ政府や州の脆弱性対応の優先順位付けを支援するための、意思決定ツリーです。
SSVCの評価は添付した画像のようなツリー構造で表現できます。このことから脆弱性の優先度合いがどの程度か把握するフローチャートのように使えると考えていただいてもよいと思います。

SSVCの意思決定ツリー

評価結果は4種類あり、緊急性の高いものから順に、Act, Attend, Track*, Trackとなっています。
Actの脆弱性はできるだけ早く脆弱性を修正することが求められており、Trackは通常のスケジュールでの対応を求められてます。説明にあるとおり、脆弱性対応に通常のスケジュール、つまり脆弱性対応の定期的なサイクルがある前提です。

今回の検討内容

Inspectorで検出する脆弱性の数はけっこうな量になる場合もあるため、まず何から始めるか検討が必要になります。
検討のためにSSVCの評価項目をSecurity Hubの評価結果のフィルターに変換して、SSVCのActに相当する、できるだけ早く修正することが求められている脆弱性をフィルターできないか検討します。

Security Hubの検出結果のフィルター

SSVCの評価項目

前述したように、脆弱性と環境を以下の4つの評価を行い脆弱性対応の優先度を決定します。

① エクスプロイトコードの状態

ソフトウェアの脆弱性エクスプロイトが利用可能のフィルター

SSVCガイドには3つの状態があります。

• None
  • エクスプロイトコードが公開されていない
• Public PoC
  • 典型的な公開PoCが存在する
• Active
  • 実際にエクスプロイトコードが使用されている

Security Hubのフィルターに変換する際は、評価項目を単純化し「ソフトウェアの脆弱性エクスプロイトが利用可能」がYESのものにします。（画像参照）
ガイドのNoneかそれ以外かの状態にするイメージです。 ただし、Log4Jのように短期間で爆発的に流行する兆しがあるものは、SSVCガイド上のActiveの状態と捉え、より緊急性が高いと判断するほうが無難と考えます。この場合は別途緊急な対応が必要となる想定です。

② 自動化可能かどうか

AWSアカウントIDでのフィルター

ガイドには2つの状態があります。

• No
  • サイバーキルチェーンの1〜4のフェーズ（偵察、武器化、配送、エクスプロイト）のいずれかで自動化できない状態
• Yes
  • サイバーキルチェーンの1〜4のフェーズのすべてで自動化できる状態

脅威アクターが脆弱性を悪用したイベントを発生させることの容易さと速度を表します。
偵察から悪意のあるコードを実行するまでの手順が確実に全て自動化可能な脆弱性、環境の場合、Yesになります。 判断に迷うポイントですが、SSVCのガイドのコメントには、効果的なバリアがある（例えば脆弱なコンポーネントがインターネットにオープンに接続されていない）ならNoと言えるという記載があります。また、脆弱性をつく攻撃を自動化できない場合もNoとなるため、脆弱性の性質も影響します。
この判断は個々の環境の状態に依るので、アカウントIDやVPC IDなどで懸念がある環境・リソースのフィルターを追加するのがよいと考えます。条件を単純化するため、脆弱性の性質は一旦考慮から外します。

③ 技術的なインパクト

重要度ラベルでのフィルター

ガイドには2つの状態があります。

• Partial
  • 脆弱性は脆弱性を含むソフトウエアの動作を限定的に制御できるようになるか、あるいは情報を暴露できるようになる
• Total
  • 脆弱性はソフトウェアの動作を完全に制御させるか、脆弱性を含むシステム上のすべての情報を完全に開示させる

SSVCの資料では技術的なインパクトはCVSSの深刻度と似ているものという記載があります。 各CVEの説明の箇所でどういった影響があるかの記載があるので、その内容を参考にする、 または単にCVSSの深刻度がHIGH以上のものを対象にするなどで同様の評価が可能という認識です。

④ ミッション

ガイドには2つの状態があります。

• Minimal
  • 以下のSupportでもEssentialでもない
• Support
  • 脆弱なコンポーネントが2つ以上の組織の中枢の機能でサポートされている
• Essential
  • 脆弱なコンポーネントは、少なくとも1つの組織の、1つ以上の中枢の機能を構成する能力を直接提供している。コンポーネントの故障は、中枢機能全体の障害につながる可能性がある（ただし、必ずしもそうではない）

どのくらい脆弱なコンポーネントが組織の中心的な業務を支えている、またはサポートしているかという観点になります。 環境やアカウントのステージまたは、機能のミッションクリティカル性などで評価できるかと考えています。

この判断も②と同様に、個々の環境の状態に依るので、アカウントIDやVPC IDなどで懸念がある環境・リソースのフィルターを追加するのがよいと考えます。 SSVCでは公共福祉 = どのくらい市民に対する影響があるかという観点がありますが、今回は省きます。

Security Hubのフィルター

デフォルトのフィルター（ワークフローのステータスがNEW, またはNOTIFIEDでレコードの状態がACTIVE）に 製品名がInspectorのフィルターを追加します。

ここに、SSVCの評価項目①と③をSecurity Hubのフィルターに追加し、以下のフィルターになります

• ワークフローのステータス = NEW or NOTIFIED
• レコードの状態 = ACTIVE
• 製品名 = Inspector
• ソフトウェアの脆弱性エクスプロイトが利用可能 = YES
• 重要度ラベル = CRITICAL or HIGH

さらにAWSアカウントIDやVPC ID、インスタンスID、などで重要な環境、リソースのフィルターを追加すると SSVCの評価項目を流用したフィルターが完成します。

Inspectorの検出結果の対応を検討される場合、上記のフィルターで検出された結果からご検討されるのが良いかと考えております。

CLIでの書き方

以下のコマンドは上記フィルターを実装した検出結果リストするコマンドです。ソートは重要度ラベル順です。 必要な場合、重要な環境、リソースのフィルターを追加してご利用ください。

aws securityhub get-findings --filters \
'{ "WorkflowStatus":[{"Value":"NEW","Comparison":"EQUALS"},{"Value":"NOTIFIED","Comparison":"EQUALS"}], "SeverityLabel": [{"Value": "CRITICAL","Comparison":"EQUALS"},{"Value": "HIGH","Comparison":"EQUALS"}], "RecordState":[{"Value":"ACTIVE","Comparison":"EQUALS"}], "ProductName": [{"Value": "Inspector","Comparison":"EQUALS"}], "VulnerabilitiesExploitAvailable": [{"Value": "YES","Comparison":"EQUALS"}]}' \
--sort-criteria '{ "Field": "SeverityLabel", "SortOrder": "desc"}'

おわりに

SSVCの評価項目を用いてInspectorの検出結果から緊急性の高い脆弱性を抽出する方法を考えてみました。
エクスプロイトコードや環境の状態は常に変わり続けるので、一度だけではなく定期的に状態を確認し、必要な対応を必要なタイミングでできるとよいかと考えます。 この記事が参考になれば幸いです。

山本 拓海(執筆記事の一覧)

エンタープライズクラウド部 クラウドリライアビリティ課
Security Hubになりたい

写真は黒猫のくま。
記事に関するお問い合わせや修正依頼⇒ takumi.yamamoto@serverworks.co.jp