インターネット露出サーバの自動特定とSSVC Exposure設定ガイド

title

TL;DR

本記事では、インターネットに露出しているサーバの特定と、SSVC（Stakeholder-Specific Vulnerability Categorization）のExposure設定方法について解説します。Amazon Inspectorを使用したインターネット露出度の自動調査方法と、FutureVulsのSSVC機能を活用した脆弱性管理自動化の実践的なアプローチを紹介します。

はじめに

サイバー脅威と脆弱性管理の課題

企業システムは、急速に進化するサイバー脅威の中で効果的な脆弱性管理が求められています。年間3万件以上の新たな脆弱性が報告される中、手動での脆弱性管理は現実的ではなく、正確さ、スピード、人的工数の面で多大な負担がかかります。そこで、自動化ツールの導入が進んでいますが、依然として優先順位付けの判断には課題が残っています。

ツールによる自動化とCVSSの限界

「Vuls」や「Trivy」のような脆弱性検知ツールやSBOMツールを使用することで、検知プロセスは自動化されますが、検知された脆弱性の数が多いため、どれを優先して対処すべきかの判断が難しいのが現状です。さらに、脆弱性の深刻度を0から10までのスコアで表現するCVSS（Common Vulnerability Scoring System）では、真に高リスクな脆弱性を絞り込むことが難しい場合があります。参考: CVSSの抱える課題

リスクベースで対応優先度を判断できるSSVCの必要性

こうした課題を解決するために考案されたのが、SSVC (Stakeholder-Specific Vulnerability Categorization）です。SSVCは、カーネギーメロン大学によって開発され、米国のCISA（Cybersecurity and Infrastructure Security Agency）でも利用されているリスクベースの優先度判断フレームワークです。参考: CISAのサイト

FutureVulsのSSVC機能についての紹介

FutureVulsは、2022年9月13日のリリースにてSSVCを実装し、リスクベースの自動トリアージを実現しました。SSVC機能により、セキュリティの専門家がいない組織でも優先順位を判断できるようになりました。さらに、現実的に脆弱性対応が可能な数まで高リスクな脆弱性を絞り込むことができます。SSVCの概要や「数千台のサーバの脆弱性管理を数名で回している」実際の導入事例、実際の運用のイメージは以下のページをご覧ください。

FutureVuls Blog「脆弱性対応に有用なSSVCと、適用について」
導入事例: ScanNetSecurity>Log4Shell のような経験はもう二度としない～ SSVC が搭載された FutureVuls を活用し、現実的な脆弱性管理を実現
FutureVulsのSSVC機能の概要と、開発・運用者目線とセキュリティ部門目線の日々の運用: チュートリアル>トリアージ

FutureVulsのSSVC機能の初期設定は、画面上で項目を選択するだけで簡単に完了しますが、その判断基準に迷うという課題があります。本記事では、SSVCの初期設定で手動での設定が必要なExposure（インターネットへの露出度）の決定方法の考え方を示し、AWS環境で自動的に調査する方法を紹介します。

SSVCの基本

SSVCではデプロイヤー、サプライヤー、コーディネーターという３種類の決定木が用意されており、利用者の立場によって決定木を使い分けます。３つの決定木については「デモ」で詳細を確認できます。この決定木を「あみだくじ」のように辿っていけば検知した脆弱性の対応優先度が４段階で決定できるイメージです。

システム運用者向けの決定木である「デプロイヤー」では、以下の4つを用いてリスク（脅威 ✕ 脆弱性 ✕ 資産重要度）を計算し、対応優先度を4段階に判別します。

リスクの種類	Decision Point	説明
脅威	Exploitation	既知のエクスプロイトの存在や攻撃のアクティブさで判断されます。
脆弱性	Utility	対象システムが保持する価値や、攻撃をツールなどにより自動化可能かで判断されます。
資産重要度	Human Impact	脆弱性が人命やビジネスに与える影響を評価します。
環境	Exposure	脆弱性の存在する資産がどの程度インターネットに露出しているかを評価します。

title

SSVCの設定の課題

決定木で考慮される4つの項目のうちExploitationとUtility（の一部）は脆弱性情報や脅威情報をもとに機械的に決定可能な項目なので判断に迷うことは少ないでしょう。

一方で、ExposureとHuman Impactについては環境によって異なる値であり、この2つはユーザが適切に決定する必要があります。SSVCの論文には決定方法の概要が書かれていますが、いざ自システムに実際に適用する際に、具体的な基準が不明瞭で決定に迷うという課題があります。

Human Impactの決定方法については、FutureVuls Blog「SSVCにおける Human Impact 決定方法例」に判断基準を詳しく記載していますので参考にしてください。

次に、手動判断が必要なもう1つの項目であるExposureの決定方法についての考え方を紹介します。

SSVCのExposure設定とガイド

SSVCのExposureとは、「対象システムがインターネットに露出しているレベル」です。対象システムのインターネット露出度に応じて以下の3段階の中から選択します。説明欄には決定のための具体例を記載しています。

Exposure Level	説明
Small	ローカルサービス/プログラム。高度に制御されたネットワーク。インターネットに接続できない閉域環境。 - インターネットへの入出力が禁止された隔離された環境
Controlled	いくつかのアクセス制限及び緩和策が実施されているネットワーク。 - インターネットに面しているがIP制限あり - インターネットに直接面していないサーバ（DBサーバなど）
Open	インターネットまたはアクセスを制限または制御できない可能性のあるネットワーク（DNSサーバー、ウェブサーバー、VOIPサーバー、メールサーバーなど）。 - インターネットに面していて無制限にアクセスできるポートがOpenしているサーバ - ShodanやNessusなどの外部スキャンツールでサービスが発見できる - 通常の保護（有害なIPやURLのブロック、ファイアウォール）なしにウェブや電子メールに接続するクライアントPC

「インターネットに露出しているが、WAF、IPS、EDR等で防御しているサーバはOpenかControlledのどちらか」は判断に悩むかもしれませんが、「インターネットに露出するサーバのExposureはOpenにすべき」です。これらのセキュリティ製品の防御能力は基本的に実際に適用しているルール次第であり、既知のすべての脆弱性のルールは用意されていません。また、新規公開された危険な脆弱性への即時対応も限界があるため、インターネットからの攻撃を完全に防ぐことは難しいです。このため、「インターネットに露出するサーバのExposureはOpen」に設定し、SSVCで分類しましょう。SSVCでImmediateやout-of-cycleと判断されたものは、セキュリティ製品の防御状況をチェックし、その後の対応を判断するのが妥当と考えています。

では、インターネットに露出しているかは実際にはどうやって判断すればよいでしょうか。

小規模なシステムであれば、インターネットからのアクセス経路は運用者が把握しており、SSVCのExposureの判断は簡単でしょう。
一方で、大規模なシステムにおいては、NWやセキュリティ機器の構成や設定が複雑であり、設計書に記載されていない想定外のアクセスパスが存在する可能性があります。また、インターネット側からネットワークスキャナを用いることも考えられますが、本番サービスに負荷がかかったり、結果から実際に内部のどの経路でどのサーバに到達するのかの調査が必要です。

なんとかしてインターネットから各サーバのポートまでの到達可能性を自動的に判断する良い方法は無いものでしょうか。

ええ、あるんです!!

インターネット露出サーバの自動特定方法

Amazon Inspectorを用いたインターネット露出度の調査

Amazon Inspectorを用いるとインターネットから到達可能なEC2を調査できます。AWS公式ページ「Amazon Inspector>ネットワーク到達可能性」によると、以下のように記載されています。

ネットワーク到達可能性の検出結果は、環境内の Amazon EC2 インスタンスへのネットワークパスが開いていることを示しています。インターネットゲートウェイ (Application Load Balancer または Classic Load Balancer の背後にあるインスタンスを含む)、VPC ピアリング接続、または仮想ゲートウェイを介した VPN など、VPC エッジから TCP および UDP ポートに到達可能な場合、これらの結果が表示されます。これらの結果では、セキュリティグループ、アクセス制御リスト、インターネットゲートウェイなどの管理が不適切であったり、潜在的に悪意のあるアクセスを許している可能性があるなど、過度に寛容なネットワーク設定をハイライトします。

Inspector単体でも脆弱性の検知はできますが、FutureVulsと連携することで、複数AWSアカウントやマルチクラウドやオンプレ環境の一元管理、リスクベースの自動トリアージ、チケット管理が可能となりセキュリティ専門家がいない組織でも脆弱性管理を現実的に回せます。詳細は、「FutureVulsとAWS Inspectorの連携:脆弱性の一元管理とリスク判断と運用者への対応指示まで自動化」を参照してください。

さて、それでは実際に設定して試してみましょう。

Amazon Inspectorの設定方法

2024年6月時点では、Amazon InspectorにはSSMエージェントを使うモードと、エージェントが不要な「エージェントレスモード」が存在します。Amazon Inspectorの設定ページで設定を有効化するだけで、EC2のインターネットからの到達可能性をチェックできます。エージェントをインストールする必要がないため、本番稼働しているEC2に特別な操作を行うことなく、インターネットからのEC2への到達性をチェックできるので、運用者にとって本番環境への影響を心配せずに確認できる便利な機能です。

エージェントレススキャンの設定方法は、FutureVuls Blogの「Amazon Inspector と FutureVuls で実現する EC2 のエージェントレス脆弱性スキャン：ハンズオンガイド」を参照してください。

AWS CLIでのインターネット露出サーバの確認方法

さて、実際にaws cliでインターネットに露出している（インターネットから到達できる）EC2の検知結果を見てみましょう。Inspectorの管理画面からも確認できますが、aws cliからも確認できます。

aws inspector2 list-findings | jq '.findings[] | select(.type == "NETWORK_REACHABILITY" and .status == "ACTIVE")'
{
  "awsAccountId": "xxx",
  "description": "On the instance i-xxxx, the port range 22-22 is reachable from the InternetGateway igw-xxx from an attached ENI eni-xxx.",
  "networkReachabilityDetails": {
    "networkPath": {
      "steps": [
        {
          "componentId": "igw-xxxx",
          "componentType": "AWS::EC2::InternetGateway"
        },
        {
          "componentId": "acl-xxxx",
          "componentType": "AWS::EC2::NetworkAcl"
        },
        {
          "componentId": "sg-xxxxx",
          "componentType": "AWS::EC2::SecurityGroup"
        },
        {
          "componentId": "eni-xxxx",
          "componentType": "AWS::EC2::NetworkInterface"
        },
        {
          "componentId": "i-xxxx",
          "componentType": "AWS::EC2::Instance"
        }
      ]
    },
    "openPortRange": {
      "begin": 22,
      "end": 22
    },
    "protocol": "TCP"
  },
  "remediation": {
    "recommendation": {
      "text": "You can restrict access to your instance by modifying the Security Groups or ACLs in the network path."
    }
  },
  ],
  "severity": "MEDIUM",
  "status": "ACTIVE",
  "title": "Port 22 is reachable from an Internet Gateway - TCP",
  "type": "NETWORK_REACHABILITY",
}

JSONには、以下の情報が表示されます。

IGW(Internet Gateway)のID
ENI(Elastic Network Interface)のID
インスタンスID
TCP/UDP、ポート番号
インターネットからEC2までのAWS内部での経路
間違ってOpenしている場合の対策方法

InspectorはネットワークのACLやセキュリティグループの設定なども賢く判断してくれています。この情報を元にSSVCのExposureを設定すれば良さそうです。

FutureVulsでのExposure設定手順

さて、インターネットへの露出度が判断できたら、あとはこれをInputとしてSSVC優先度を計算していきましょう。

FutureVulsではシステム単位でグループを作成し、グループにサーバ等のアセットやユーザを割り当てて管理します。そして、グループ単位でSSVCのExposureなどを設定できます。詳細はマニュアルを参照してください。

それでは、同一グループの中に「DMZなどにあるPublicなWebサーバ」や「PrivateなネットワークにあるDBサーバ」など、Exposureが異なるサーバが混在している場合はどのように設定すればよいでしょうか。このような場合はロールにて設定できます。同一グループ内に、Network ReachableやPublicといったネーミングのロールを作成し、Inspectorにてインターネットから到達できると判断されたEC2を所属させてください。SSVCの優先度判断時にそのサーバが所属しているロールのSSVCの設定が設定されている場合は、ロールの値を参照して対応優先度を計算します。

下はFutureVulsのSSVC設定のための実際の画面です。Epxposureを3段階から選択するだけで設定が完了します。

roleのSSVC設定

その後の、開発・運用者目線とセキュリティ部門目線の脆弱性管理の日々の運用については、「チュートリアル>トリアージ」に詳細を記載していますのでぜひご覧ください。脆弱性管理の運用が徹底的に自動化されることがおわかり頂けます。

まとめ：効果的な脆弱性管理を実現するSSVCとFutureVuls

企業が直面する脆弱性管理の課題に対処するためには、効果的なリスクベースの優先順位付けが不可欠です。従来のCVSSスコアだけでは高リスクな脆弱性を絞り込むことが難しく、手動での管理は現実的ではありません。こうした課題を解決するために、SSVC (Stakeholder-Specific Vulnerability Categorization) が注目されています。

SSVCは、脆弱性のリスクを総合的に評価し、優先順位をつけるためのフレームワークであり、カーネギーメロン大学によって考案され、米国CISAでも採用されています。FutureVulsはこのSSVCを実装しており、リスクベースのトリアージをサポートしています。

SSVCでは、Exploitation、Exposure、Utility、Human Impactの4つの決定要素を用いて脆弱性の優先順位を判断します。このうち、Exposure（対象システムがインターネットにどの程度露出しているか）は手動設定が必要ですが、Amazon Inspectorを活用することで自動的に調査可能です。

Amazon Inspectorは、インターネットからの到達可能性を評価する強力なツールです。これを利用することで、SSVCのExposureを正確に設定できます。FutureVulsでは、サーバ単位での柔軟なExposure設定が可能であり、大規模なシステムにおいても効率的に脆弱性を管理できます。

本記事を参考に、脆弱性管理の課題に対処し、リスクベースの優先順位付けを実践してみてください。SSVCとFutureVulsを活用することで、現実的で効果的な脆弱性管理が実現します。

SSVC機能の詳細な説明、デモ、無償トライアルのご要望は、こちらからお気軽にお問い合わせください。