【要点抽出】政府情報システムにおける脆弱性診断導入ガイドライン

「脆弱性診断」と一口に言ってもその内容はピンキリですが、分かりやすい基準となりそうなガイドラインがデジタル庁から出ていました。2022年6月に出たので1年ほど前のものですが、読んでみました。

https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/3bc45d3c/20220630_resources_standard_guidelines_guidelines_08.pdf

何の本?

本書は政府情報システムを対象に、脆弱性診断をかける際の前提知識や基準を記したものです。
どんなシステムを対象に・どんな種類の診断を・どのタイミングで・どのレベルの技術者にやってもらうべきか非常に分かりやすくまとまっています。
民間システムにも十分に役立てられるものだと思います。


構成は?

付録を除いて3章構成です。
全27ページしかないので、要点抽出するまでもなく30分あれば読めます。

  • 1章 前書き

  • 2章 脆弱性診断の概要

  • 3章 脆弱性診断の実施基準


2章 脆弱性診断の概要

大前提として、脆弱性診断だけやればOKではなく、脆弱性の未然防止のための取り組み(レビュー等)と組み合わせることが重要です。

  • 脆弱性の分類について。
    私はこの図が非常に分かりやすいと思いました。
    組織のセキュリティ要件やチェックリストにまで対処方針が落とし込まれている脆弱性が(B)、要件化は出来ていないけど開発の有識者などが「よしなに」対処してくれる脆弱性が(A)です。
    脆弱性診断でカバーできるのは(B)を含む(A)であり、過去の知見から防げるべき脆弱性を作ってしまっていないかを洗い出します。
    一方、(Ā)は診断では発見できず、バグバウンティなどの「未知を探す」取り組みが別途必要です。

図2-1 システムにおける脆弱性の分類
  • 脆弱性診断の種別について
    本書では「プラットフォーム診断」「Webアプリ診断」「スマートフォンアプリ診断」の3つを扱っています。以下は原文「2.2 一般的な脆弱性診断の種別」の内容を表形式にまとめたものです。

表1.「2.2 一般的な脆弱性診断の種別」を元に作成
  • 診断ベンダの選び方について
    「情報セキュリティサービスに関する審査登録機関基準」 を満たすことと、加えて技術力を測るために以下の観点が示されています。
    ・OSCP、 OSWA、 GWAPT、 GPEN、 GMOBまたはその上位資格の保有
    ・CTF等での上位入賞実績
    ・CVEの付与された脆弱性の発見数

    また、こうした高度なスキルを持つ技術者が診断ベンダの中にいます。というだけではなく、どの程度その技術者が自社に対する診断業務に携わってくれるのかまで確認せよとあります。

    (余談:診断ではなくペネトレーションテストの話ですが、私の所属企業でも、過去に某ベンダから「弊社のXX(個人)はこんな賞をとってて凄い!世界一のハッキング能力!」みたいな営業を受け、トップダウンの指示により試しに契約したことがありました。しかし、実際にはそのご本人はさほど診断業務に関わっておらず、実務は配下の方々が回しているだけで、当然ながら何も有益な指摘は得られない結果になったことがありました)

  • 発見された脆弱性の深刻度評価について
    多くのベンダがCVSSなどの基準に沿ってCritical、High、Medium、Lowみたいな段階に分けて報告してくれますが、それを鵜呑みにせず、自社なりの目線で再評価せよと書かれています。

  • 診断に伴うリスクについて
    診断を行うとシステムの安定稼働に影響を出してしまう恐れがあります。これについては、検証環境で診断をする、事前にバックアップを取っておく、システムのサービス提供時間帯を避ける、関係者に事前に周知しておくといったケアも必要です。


3章 政府情報システムにおける脆弱性診断の実施基準

いよいよ具体的な基準についてです。

(1)どのあたりのシステムに診断をかけるか

脆弱性診断には「構築時診断」「定期診断」の2種類あります。
構築時診断を行う際のターゲットの絞り方は以下の通りです。

表2.「3.1 脆弱性診断の対象システム」「3.2 脆弱性診断の実施範囲」を元に作成

定期診断は診断対象の把握が肝心です。
インベントリ管理、あるいはそれができていなければOSINT等による外部目線での診断対象の洗い出しを行います。
その上で各システムの診断範囲を決めますが、大規模な組織やシステムでは全量を一気に診断できません。対象の絞り方として以下が書かれています。

  • 実施規模の目安として、プラットフォーム診断は10〜30IPアドレス程度、Webアプリ診断は50〜100リクエスト程度、スマートフォンアプリ診断は10〜20画面程度

  • サイトのトップページから辿れる範囲で行うことや、同様の作りの画面が複数ある場合は代表する1画面のみを診断対象とすること等の選定方針を決めておく

(2)診断に求める要件

診断種別によらない共通要件と、診断種別ごとの要件が書かれています。

共通要件は以下です。

<必須>

  • 経済産業省の「情報セキュリティサービスに関する審査登録機関基準」の「脆弱性診断サービス」 の認定を取得したセキュリティベンダーであること

  • 上記認定基準における「技術要件」と「品質管理要件」を満たす人員が 1 名以上診断に参画すること

  • 2年以上の実務経験を有する者が診断に参画すること

  • ツールを用いてもよいが、手動でも診断エラーや誤検出を精査すること

  • 診断前に実施計画書を提出すること(計画書に含むべき内容は割愛)

  • 診断結果の報告書には、脆弱性の概要、深刻度、影響、対策方法、検出したパラメータ、入力した文字列を含み、PDF形式であること

  • 脆弱性の影響は、可能な範囲で実証し、発生可能性や脅威シナリオに基づき記述すること。攻撃時のスクリーンショットも出来るだけとること

  • 脆弱性の改修後に再診断を行うこと
    再診断は報告書の納品から最低1か月以内、1回以上できること

<推奨>

  • 上記「診断ベンダの選び方」で挙げた条件に該当するものが1名以上診断に参画すること

  • 診断前に対象システムの責任者や担当者に説明会を実施すること

  • 脆弱性の深刻度はCVSS v3.1基本評価基準に基づく5段階評価とし、算定方法も明記すること

  • 報告書は分かりやすく(セキュリティに1年従事したくらいの人が分かるように)書くこと

  • 診断結果の報告会を実施し、その場には作業従事者が同席すること

<任意>

  • 休日夜間の診断にも対応可能であること

  • 診断時に使うネットワーク帯域を制限可能であること

診断種別ごとの要件は以下です。

表3.「3.3 脆弱性診断の実施要件」を元に作成

(3)検出された脆弱性の対応方針

既に悪用されている脆弱性ならとにかく急いで是正し、そうでないなら深刻度に応じて対応基準を決めて進めてね。とあります。


感想

本書は個人的には非常に「わかりみが深い」内容でした。
規模が大きいが内部に診断部隊までは抱えられない会社は、外部のベンダに診断を委託することが一般的です。外部に委託すると、委託先のリソースにより全てのシステムを診断できないことがあり、絞る必要があります。
その意味で、診断対象システムの選び方などは私がこれまで経験してきたことと比べても「そうだよね」と思う内容でした。
一方で、診断ベンダの選び方は「以前からお願いしていてよく当社環境をご存じだから」みたいな理由で選んだことしかなく、ここで書かれている資格要件まで踏み込んでいないためにとても参考になりました。

実際には、これ以外にペネトレーションテストとか、手動診断まで出来ないシステムはツール診断だけでもかけるとか、あわせてやる事は色々あります。コストは無限にかかります。
「診断やってます」の一言で終わらせるのではなく、その手法や基準まで踏み込んで各社比較できると、他社比を踏まえてどこまでコストをかけるべきか現実的な落としどころが見えてくるだろうと思いました。

***はじめての方へ***
これは何のnoteだ?と思われた方はこちらをご覧ください。
これまでにまとめたガイドライン類の一覧はこちら


この記事が気に入ったらサポートをしてみませんか?