脆弱性診断後の対応優先順位 ― 限られた工数での意思決定
ある企業の受注管理Webアプリケーションが、外部の脆弱性診断を受け、18件の指摘を受けた。内訳はCritical 2件、High 4件、Medium 8件、Low 4件である。3週間後に新機能のリリースが予定されており、そこまでに改修へ投入できる工数は25人日である。
指摘の主要なものは次のとおり。 (a) OSコマンドインジェクション。管理者画面のファイル出力機能に存在し、利用には管理者権限でのログインが必要。管理者画面は社内VPNからのみ到達可能。改修8人日。 (b) SQLインジェクション。取引先向けの検索画面に存在し、ログイン前の入力欄が対象。インターネットに公開されている。改修5人日。 (c) 認可不備(IDOR)。URLのIDを書き換えると他店舗の受注情報が閲覧できる。ログインは必要だが、取引先ユーザなら誰でも実行可能。改修3人日。 (d) CSRF対策の欠如、XSS(反射型)、セッション固定などが続く。
WAFは導入済みだが、ルールはシグネチャベースで、暗号化やエンコードを変えた回避入力には対応できない。リリースを延期すれば工数は確保できるが、取引先との契約で新機能の提供時期が定められており、延期には違約金が発生する。
1. 25人日の中で、どの指摘から対応すべきか。優先順位と根拠を述べよ。
Read the worked answer
優先順位:(b)→(c)→(a)の順に着手し、残り工数を(d)群に配分する。
判断の軸 脆弱性対応の優先順位は、スコアの高低ではなく「到達可能性」「必要な前提条件」「悪用された場合の影響」の3つで決める。
(b) SQLインジェクションを最優先
- 到達可能性:インターネット公開かつログイン前の入力欄が対象で、認証情報を持たない第三者でも試行できる。
- 前提条件:なし。自動スキャンで発見されやすく、実際に攻撃されるまでの時間が短い。
- 影響:DB全体の情報漏えい、場合によってはデータ改ざん。
- 工数5人日で、費用対効果が最も高い。
(c) 認可不備を2番目
- 到達可能性:ログインは必要だが、取引先ユーザなら誰でも可能。取引先は多数存在し、退職者や取引停止先のアカウントが残っている可能性もある。
- 影響:他社の受注情報が見える。これは自社だけでなく取引先の機密漏えいであり、契約上の重大な問題になる。
- 工数3人日と小さく、確実に直せる。
(a) OSコマンドインジェクションを3番目
- 到達可能性:管理者権限でのログインが前提で、さらに社内VPNからのみ到達可能。
- 影響は最大級(サーバ乗っ取り)だが、前提条件が重い。ただし「管理者権限を持つ内部関係者」が攻撃者になり得る点、VPN接続端末が侵害された場合には前提が崩れる点は無視できない。
- 工数8人日。25人日のうち5+3=8を使った残り17人日で対応可能だが、(d)群とのバランスを考える。
残りの配分 (a)に8人日、残り9人日を(d)群へ。CSRFとセッション固定は認証後の操作に影響し、XSSは利用者間の攻撃に使われる。Medium以下でも、管理画面や決済画面に関わるものは優先度を上げる。
見落としやすい点 「Criticalだから最優先」という機械的判断は誤りである。本件ではCriticalの(a)より、Highの(b)(c)の方が実際のリスクは高い。診断結果のスコアは一般的な深刻度であり、自システムの公開範囲・権限設計を反映していない。
2. WAFによる緩和はどの程度期待できるか。限界と残存リスクを述べよ。
Read the worked answer
期待できる範囲 シグネチャベースのWAFは、既知の攻撃パターン(典型的なSQLインジェクションの文字列、OSコマンドの区切り文字など)を遮断する。改修が間に合わない項目に対する仮想パッチとして、攻撃の成功率を下げる効果はある。特に(b)のような自動化されたスキャン攻撃には一定の抑止力がある。
限界
- 回避入力への弱さ:暗号化、多重エンコード、SQLの構文を変形した入力、パラメータの分割などでシグネチャを回避できる。WAFは「入力を検査する」仕組みであり、アプリケーションの論理的な欠陥を直しているわけではない。
- (c)には無力:認可不備は「正当な形式のリクエストで、他人のIDを指定する」攻撃である。リクエスト自体は正常に見えるため、シグネチャでは検知できない。WAFを理由に(c)の改修を後回しにするのは誤りである。
- 運用負荷:誤検知による正当な取引の遮断が起きる。ブロックモードにすると業務影響が出るため、監視モードで運用されがちで、その場合は防御効果がない。
- 設定の陳腐化:新機能のリリースでパラメータが増えると、WAFのルールが追随せず空白が生まれる。
残存リスクの評価 WAFを導入しても、アプリケーション側の欠陥は残り続ける。したがって「WAFがあるから未改修でも安全」という説明はできない。経営層に対しては、「WAFは攻撃の難易度を上げるが、ゼロにはしない」と明示し、未改修項目については次回リリースまでの期限付きのリスクとして管理する。
現実的な組み合わせ (b)はWAFの仮想パッチ+早期改修、(a)はVPNと管理者権限の多要素認証強化で前提条件を重くしつつ改修、(c)はWAFでは守れないため改修を必須とする。この切り分けが要点である。
3. リリース延期か、範囲を絞っての強行かを判断せよ。経営層への説明の仕方も含めて述べよ。
Read the worked answer
結論:リリースは予定どおり実施し、脆弱性改修をリリース条件に組み込む。ただし未改修項目は期限付きで管理する。
判断の根拠 25人日の枠で(b)(c)(a)と主要な(d)群をこなせる見込みであり、延期しなくても重大な脆弱性は塞げる。延期のコストは違約金という明確な損失である一方、範囲を絞ることのリスクは「未改修項目が残る」ことであり、これは期限と監視で管理できる。両者を比べると、範囲を絞る方が損失が小さい。
ただし条件が2つある。第一に、(b)(c)の改修と回帰テストが3週間で確実に終わること。終わらない場合は新機能の一部を次回に回す。第二に、未改修項目についてWAFの仮想パッチと監視をセットで適用すること。
経営層への説明の構成
- 事実:18件の指摘のうち、外部から到達可能で悪用が容易な2件を最優先で改修する。Criticalの1件は前提条件が重いため、多要素認証の強化と組み合わせて段階的に対応する。
- 判断:延期による違約金を回避しつつ、実リスクの高い脆弱性は塞ぐ。
- 残存リスク:未改修項目は存在する。WAFと監視で緩和するが、ゼロにはならない。次回リリースまでに解消する計画を示す。
- 判断の変更条件:回帰テストで重大な不具合が出た場合、または改修が3週間で完了しない場合は、新機能の一部を次回に回す。
避けるべき説明 「WAFがあるので安全」「診断の指摘は18件だが大したことはない」という説明は、事故が起きた際に説明責任を果たせない。リスクを残すと明示し、その管理方法と期限を示すことが、意思決定者としての説明になる。
追加で確認すべきこと 新機能そのものに脆弱性が持ち込まれていないか、リリース前に新規画面への簡易診断を実施する。既存の18件を直しても、新機能で同じ種類の欠陥を作れば意味がない。