人の手で検証した指摘に基づく ペネトレーションテスト。
人が行うペネトレーションテストです。悪用は手作業で試み、すべての指摘は報告書に載る前に再現します。目的は脆弱そうな箇所を列挙することではなく、いま御社が外部にさらしているもので攻撃者が実際に何をできるのかを示すことです。
スキャナーでは答えられず、ペネトレーションテストで分かること
自動化ツールは脆弱に見える箇所を指し示します。ペネトレーションテストは、本当に悪用できるものは何か、そのアクセスがどこまで届くかを実証します。違いが表れるのは連鎖です。単体では低く評価される権限の欠陥も、そのユーザーが触れてはならないデータへつながった瞬間に重大になります。その経路をツールだけで組み立てることはできません。そして修正の優先順位を変えるのは、ラベルではなく経路のほうです。
- すべての指摘は報告書に載る前に人の手で再現します。ツールの生出力は成果物ではありません。
- リスクは公開データベースの一般的な点数だけでなく、御社の事業への影響で記述します。
- 誤検知がお手元に届くことはありません。再現できなかったものは文書に載せません。
- 悪用の経路は段階ごとに記録します。御社のチームが自分で再現し、修正を確認できるようにするためです。
実施内容
以下は標準的な案件での既定の範囲です。スコーピングの段階で、いずれも無償で調整できます。
- 認証、セッション管理、パスワード再設定
- オブジェクト単位の水平・垂直の権限確認
- クエリ、コマンド、テンプレートへのインジェクション
- 業務ロジックと迂回できてしまう処理の流れ
- ファイルのアップロード、処理、配信
- ヘッダー、Cookie、CORS の設定
- リソースの列挙と推測しやすい識別子
- アカウント間・テナント間のアクセス制御
- スキーマ検証と想定外の型の扱い
- 回数・コスト・自動化された濫用に対する上限
- サービス間認証と秘密情報のローテーション
- レスポンスに含まれる過剰なデータ
- 外部に露出した境界と忘れられたサービス
- サポートが切れたバージョンと未適用の修正
- 環境間およびネットワーク間の分離
- 境界から到達できてしまう内部サービス
- TLS の設定と通信の終端
- 初期侵入地点からの横展開
- ID プロバイダとフェデレーションの流れ
- 二要素認証：適用範囲、迂回、復旧手段
- 継承された権限と積み上がった許可
- サービスアカウントとコード内の認証情報
- 複数端末のセッションと失効処理
- 新規登録と利用開始までの手続き
- Android・iOS アプリ（ローカル保存領域を含む）
- アプリと API の通信、証明書ピンニング
- 改ざん対策と、侵害済み端末上での挙動
- 社内 Wi-Fi、ゲスト用ネットワーク、両者の分離
- オンプレミス設備と、そこからクラウドへ届く範囲
- キオスク端末、レジ端末、共用機器
- インジェクション：SQL、NoSQL、LDAP、コマンド、テンプレート
- 認証、認可、IDOR、権限昇格
- SSRF、XXE、安全でないデシリアライズ
- 業務ロジックと決済フローの欠陥
- 影響を実証できる XSS、CSRF、クリックジャッキング
- 弱い暗号、推測可能なトークン、脆い JWT
実施形態
範囲に応じて調整ブラックボックス
内部情報を持たず、外部の攻撃者と同じ立場から始めます。御社の攻撃面が見知らぬ相手に何を差し出すのかを測るもので、誰も露出に気づいていなかった資産がしばしば見つかります。
グレーボックス
認証情報と構成の概要をお預かりします。同じ期間で最も広く見られる方式です。労力が偵察ではなく悪用に向かうためで、権限まわりの欠陥はここで表に出ます。
ホワイトボックス
コード、設定、ドキュメントを参照します。外部からはめったに見えない経路まで届きます。競合状態、エラー処理、いくつもの層の下に埋もれた機微なロジックなどです。
ペネトレーションテストが割に合いやすい局面
年に一度の形式的な行事ではありません。攻撃面が変わったとき、あるいは外部から問われる時期が近いときなど、費用以上のものが返ってくる局面があります。
作り直し、ID プロバイダの入れ替え、環境の移行は、誰も見直さなくなった前提を動かします。変更前に検証するほうが、実トラフィックが乗った後に気づくより安く済みます。
大企業との契約、セキュリティ質問票、調達手続きでは第三者による検証が求められるのが通例です。報告書は自己申告に頼らず、客観的にそれに答えます。
新しいチーム、新しいサービス、新しい連携。急な成長は、誰も全体を把握できていない攻撃面と、暫定措置として付与されたまま戻されていない権限を生みます。
古い社内システム、管理画面、昔の連携は、何年も対象外のままになりがちです。「社内向けだから心配ない」と見なされていることが、まさにその理由です。
進め方
[パイプライン]範囲と交戦規則
最初のパケットを送る前に、対象に含めるもの、含めないもの、実施を許可する時間帯、計画から外れた場合の連絡先を文書にします。重大な発見があった場合の中止基準も取り決め、深刻な発見が報告書を待たずその日のうちに届くようにします。
偵察と全体像の把握
実際の攻撃面を組み立てます。ドメイン、サブドメイン、公開中のサービス、使用技術、入口、そして環境について既に公になっている情報。資産台帳から漏れているものが表に出るのはこの段階です。到達できるステージング環境、忘れられた管理画面、検証のために立てたまま動き続けているサービスなど。
スキャンと選別
自動化はここで、そしてここでのみ使います。量をさばき、候補を出す役割です。すべての結果は人手で選別します。ツールが挙げるものの大半は、実際に再現しようとすると成立しないからです。残ったものが、悪用の仮説になります。
手作業による悪用
テストがスキャンと分かれるのはここです。欠陥を連鎖させ、業務ロジックを探り、権限昇格を試み、保護されているはずのデータに届くかを確かめます。常に取り決めた規則の範囲内で、本番の可用性には手を触れません。
侵入後の到達範囲
扉を見つけること自体は目的ではありません。重要なのはその先です。最初の足がかりがどこまで届くか、そこから何を読め、何を変え、どこまで居座れるか、別のシステムに到達できるかを測ります。その測定こそが、技術的な評価値を事業リスクに変えます。
報告と再テスト
報告書には再現手順、影響、推奨する修正を記載し、経営向けの読み方と技術的な詳細を分けて構成します。是正後は対処された項目を再検証し、何が閉じたかを記録します。修正済みの指摘は、誰かが確認して初めて成立するからです。
作業の根拠となる公開基準
公開され広く認められた方法論に沿って作業します。そのため事業者間で範囲を比較でき、監査の担当者は私たちの言葉を鵜呑みにせず、何が対象になったかを自分で確認できます。
- OWASP WSTG
- OWASP Web Security Testing Guide は、認証・セッション・認可・入力検証・業務ロジックといった区分で対象範囲を整理し、何を確認したのかを示す明快な土台になります。
- OWASP API Security
- API のリスク一覧は、従来の Web 検証では扱いにくい領域を押さえます。オブジェクト単位の権限確認、過剰なデータ露出、無制限の消費などです。
- PTES
- Penetration Testing Execution Standard は、事前調整から報告までテストの各段階を規定しており、上記の流れの背骨になっています。
- MITRE ATT&CK
- 攻撃側の戦術と技術の一覧です。実施した内容に共通の名前が付くため、防御チームは各手順を検知が捉えたもの——あるいは見逃したもの——と突き合わせられます。
- NIST SP 800-115
- セキュリティ検証に関する NIST の技術ガイドで、計画・実施・事後の活動を定義しています。契約要件で最も多く引用される参照文献です。
- CVSS
- スコアは技術的な深刻度を標準化しますが、あくまで入力の一つです。優先順位は御社の状況における影響に従い、その内容を数値の横に平易な言葉で示します。
成果物
二層構成 · NDAエグゼクティブサマリー
予算と優先順位を握る方のための短い読み物です。何を検証し、どれが本当のリスクで、何を判断すべきか。専門用語を使わずに書くので、取締役会でもそのまま通ります。
完全な再現手順つきの指摘
各項目に、リクエスト・レスポンス・証跡を添えた手順を段階ごとに記載します。開発者は問い合わせることなく再現でき、テストを実施した者に頼る必要もありません。
影響と優先順位の評価
技術的な深刻度と事業への影響は別々に示します。両者は必ずしも一致しないからです。推奨する順序には是正の手間も織り込むため、最も高くつくうえに急ぎでない項目から着手する事態を避けられます。
御社に即した是正の指針
御社のコードと構成に当てはめた助言であり、ドキュメントから引き写した一般論ではありません。取りうる道が複数あるときは、それぞれの得失を記します。
監視状況との突き合わせ
実施した内容を手法ごとに整理した一覧です。ログやアラートが何を捉えたかと比較できるため、検知担当にとっては脆弱性一覧と同じくらい多くのことが分かります。
再テストと完了報告書
是正後に対処された項目を見直し、最終状態を記録します。この報告書は、対応が完了した証跡を必要とする取引先、パートナー、監査人に提出できます。
よくある質問
既定では可用性の検証は行いません。サービス妨害をはじめ高リスクな行為は、明確な依頼と時間帯の合意がない限り対象外です。本番に影響しうる検証は、同等の環境へ移すか、合意した時間帯に実施し、その間ずっと直通の連絡経路を開いておきます。
範囲の定義、利用者の役割ごとの検証用アカウント、そして連絡の取れる技術担当者です。境界の防御機構が検証を妨げる可能性がある場合は、それを対象に含めるか例外扱いにするかを一緒に決めます。防御機構を試すことと、アプリケーションを試すことは別の目的だからです。
スキャンは見つけたものを既知のデータベースと突き合わせ、一覧を返します。ペネトレーションテストは実際に悪用を試み、欠陥を連鎖させ、アクセスがどこまで届くかを測ります。スキャンは安価で継続的な監視に向きます。手作業の検証は、一覧では答えられないこと、つまりその項目が御社の状況で本当に悪用できるのかに答えます。
使えます。エグゼクティブサマリーは技術者以外の読者に向けて書かれており、取引先・パートナー・監査人へそのまま渡せます。技術的な詳細は別章にまとめてあり、再テスト後に発行する完了報告書は、調達手続きで証跡として受け入れられることが多い書類です。
リスク次第です。本番を忠実に写したステージング環境があるならそちらを優先します。より踏み込んだ検証ができるためです。本番しか存在しない場合——こちらが一般的ですが——破壊的な操作を制限し、時間帯を取り決め、期間中は連絡経路を開いたままにします。
開始前に取り決めた中止基準に従います。重大な発見は最終報告書を待たず直ちに報告し、対処に必要な最小限の情報を添えます。状況が求める場合は、封じ込めが済むまで実施を止めます。
変化の速さによります。継続的にリリースするアプリケーションは毎週のように攻撃面が変わり、年に一度の検証では、もう存在しないシステムを見ていることになります。主要な範囲を定期的に検証しつつ、構成が変わるたびに的を絞った検証を足すやり方が一般的です。新しい連携、新しい ID プロバイダ、新しい環境などのタイミングです。