American Bankerの報道によると、4月に発生した単一のVPN脆弱性が原因で、Marquis Softwareのインフラを使用する70以上の金融機関でデータ侵害が発生しました。パッチはすでに存在していました。被害を受けた機関の多くも、最近のペネトレーションテストの記録を保有していたはずです。それでも、被害はポートフォリオ全体に拡大し続けました。
数字は明快です。標準的な年1回の外部ペネトレーションテストでは、実際にアクティブなテストを行う期間は2〜3週間程度です。つまり、実際の運用環境が検証されない期間が、年間でおよそ345日も生じることになります。
MandiantのM-Trends 2026レポートによると、2025年の侵害発覚までの中央値は14日で、複数年にわたる減少傾向が反転しています。また、スパイ活動を目的とした攻撃者の平均滞在時間は122日に上っています。
CrowdStrikeの2026年グローバル脅威レポートでは、金融サービスが対話型侵入のターゲットとして第4位にランクされています。攻撃者は年次評価と評価の間を悠長に待つようなことはしません。しかし従来のモデルは、そうした前提の上に成り立っていました。
規制当局が定めた最低基準と、それを上回るペースで進化する脅威
PCI DSS、FFIEC、NYDFSはいずれも、要件やガイダンスの中でペネトレーションテストに言及しています。ただし、年1回の実施で十分であるとは、どの規制も明示していません。
PCI DSS 4.0の要件11.3.1では、重大なインフラやアプリケーションのアップグレードまたは変更後に外部ペネトレーションテストを実施することを義務付けています。FFIECのIT審査ハンドブックでは、ペネトレーションテストを単発の年次イベントではなく、継続的な脆弱性管理の一環として位置付けています。NYDFSのSection 500.05は、2023年に改正された23 NYCRR 500で強化された継続的なモニタリング義務に加え、年次テストの実施を義務付けています。
これらのフレームワークはいずれも、変更が生じた際にテストを実施することを前提として設計されています。規制上の最低基準は、四半期ごとのリリースサイクルで重大な変更が行われる機関を念頭に置いて策定されたものです。
しかし、そのサイクルは現代の銀行インフラの実態とはかけ離れています。デジタルバンキングのリリース、クラウドワークロードの移行、フィンテックAPIの統合、サードパーティポータルの立ち上げ、M&Aに伴うシステム統合作業など、年次テストの合間にも未検証の攻撃対象領域は次々と生まれています。
今や問うべき問いは、「昨年テストを実施したか」ではありません。「実際に変更された箇所をテストしたか」です。
345日間の空白が生み出すもの——実例を基に
あるリージョナル銀行でのエンゲージメントで、Sprocketのテスターは顧客向けの住宅ローン申請ポータルに問題を発見しました。このポータルは、銀行が自社保有のサブドメインで公開しているものです。運営はサードパーティのプラットフォームベンダーが担当しており、申請者には銀行のブランドとホスト名が表示されます。このアセットは外部テストのスコープ内に含まれていました。
そのプラットフォームは、テナントIDを指定することで組織レコードを返すAPIエンドポイントを公開していました。このエンドポイントは認証もセッションも一切必要としていませんでした。さらに、プラットフォームのクロスオリジンポリシーにより、第三者のサイトがユーザー操作なしに訪問者のブラウザから同じリクエストを発行できる状態になっていました。
テナントID自体はポータルの公開ファイルに記載されていたため、未認証の呼び出し元がこれを推測する必要すらありませんでした。テナントIDを1つインクリメントするだけで、同じプラットフォーム上の別の機関のレコードが返されます。範囲を繰り返し反復することで、そのプラットフォームを利用しているすべての金融機関のレコードと、ベンダー自身の内部テナントのレコードも取得できました。
返却されたレコードは汎用的なものではありませんでした。各レコードには、担当者の氏名、ビジネスメールアドレス、直通電話番号、役職、さらにプラットフォームが特定の担当者に借り手の申請を紐付けるために使用する内部コードが含まれていました。
この内部コード自体にも重大な問題がありました。有効なコードを持つ呼び出し元であれば、特定の担当者名義でその担当者が所属する機関に対して借り手の申請を送信でき、プラットフォームはその送信を正規の融資審査パイプラインへの申請として処理してしまいます。
この脆弱性を作り込んだのは銀行ではなく、プラットフォームベンダーです。銀行の過去の年次外部評価では、テスト当時のスコープに含まれていたホスト名を対象としていた可能性がありますが、自動スキャナーではこの問題を検出することはできません。
発見には、未文書化のエンドポイントに対して連続したテナントIDを試行し、返されたレコードが他の機関に属することを確認するという手作業のプロセスが必要でした。また、テストは本番環境に対して実行する必要がありました。
この問題が単なる技術的な問題ではなく、規制上の問題でもある理由は、そのダウンストリームリスクにあります。共有プラットフォーム上の他のすべての機関に属するデータが、銀行のホスト名を通じて引き出せる状態にあったのです。
その脆弱性に起因する詐欺、フィッシング、コンプライアンス上のインシデントが発生した場合、攻撃者が実際にどのテナントのデータを使用したかに関わらず、URLに表示されている機関に問題が帰属することになります。
継続的テストが上記エンゲージメントへの実務的な回答
上記の問題は、年次モデルではほぼ見逃されます。その理由は3つあり、いずれも今回のエンゲージメントに直結しています。
このアセットは、銀行の年次ペネトレーションテストがスコープ設定された時点ではなく、ベンダーが銀行をプラットフォームにオンボードした時点で、銀行の外部フットプリントに加わりました。エンゲージメントのスコープが6ヶ月前のインフラのスナップショットに基づいて設定されていた場合、このホスト名はリストに含まれていなかった可能性があります。アタックサーフェス管理は、次回の年次スコープに関する打ち合わせを待つのではなく、新しいホストや新たに公開されたサービスをテストのトリガーとして扱うことで、このギャップを埋めます。
また、このアセットは機関が年次スコープから除外しがちな類のものでもありました。銀行自身のサブドメインに表示されるベンダー運営のポータルは、スコープ設定の議論においてグレーゾーンに位置します。
銀行のアプリケーションではなく、ソースコードへのアクセスもなく、リリースの管理もできない。そしてベンダーが独自のセキュリティプログラムを持っている。
プラットフォームベンダーが自社コードのテストに責任を持つと判断し、そのホスト名をエンゲージメントのスコープから除外することは、機関として合理的な判断です。しかし、継続的な外部偵察はその境界線を考慮しません。
銀行が所有するドメイン上でホスト名がインターネット上からアクセス可能であれば、それは銀行の外部攻撃対象領域の一部です。銀行の最新のスコープ文書にそのホスト名が記載されていたかどうかにかかわらず、銀行の境界を探索する攻撃者はそのホスト名に遭遇します。
また、この問題の発見にはスキャナーの出力ではなく、人による能動的なテストが必要でした。ホスト名をスキャンした脆弱性スキャナーは、エンドポイントが応答可能であること、CORSポリシーが緩いこと、認証ヘッダーが欠落している可能性があることを報告し、そこで終わるでしょう。
テナントIDの反復試行、クロステナントでのデータ返却の検証、スタッフ紐付けコードを申請偽造のシナリオにつなげる分析——これらをスキャナーは行えません。自動化はリスクの可能性を示します。実際に悪用可能かどうか、そしてその場合のダウンストリームへの影響を確認するのは、テスターの役割です。
Sprocket Securityはこの原則に基づいて継続的なテストモデルを運用しています。その結果として得られる証明書は、12ヶ月前のスナップショットではなく、テスト実施時に実際に存在していたインフラに対してテストを行ったことを示すものです。
345日間のギャップは構造的な問題であり、頻度の問題ではない
345日間のギャップはマーケティング上の数字ではありません。これは年次テストモデルに内在する構造的な特性です。規制当局がテスト要件を策定したのは、機関が変更が生じた際に、変更された箇所をテストすることを前提としていたからです。
しかし多くの機関では、エンゲージメントのスコープ設定時点に存在していたものを、決められたスケジュールでテストし、その結果として得られた証明書を現在のリスク状況の説明として扱っています。その説明は、テスト終了後から毎日精度を失い続けています。
このギャップを埋めている機関は、より高頻度でテストを実施しているわけではありません。自社のインフラの実態に即してテストプログラムが機能している機関が、そのギャップを解消しているのです。
