Mastercard GLB 12772アラート|返金・チャージバック率5%超過時の72時間以内の調査要件

コンプライアンスアラート/QSA視点

サブマーチャントの「返金+チャージバック」率が5%到達、72時間以内の調査が必須
Mastercard新ルールが7月24日施行、PF(ペイメントファシリテーター)はどう備えるべきか?

施行日:2026年7月24日

近年、「詐欺加盟店モニタリング」に関する議論が広がっています。Mastercardは、GLB 12772という文書を公開し、「潜在的な詐欺加盟店モニタリング」に関する基準を改訂したとみられます。

本資料は会員向けチャネルを通じてのみ配布され、一般公開されていないため、現時点では公開情報や間接的な情報源をもとに分析しています。

Mastercard認定のMMSP(加盟店モニタリングサービスプロバイダー)であるAustremeの公式サイトでは、GLB 12772に基づくMastercardの新たな取引リスク管理要件に関する情報が確認されています。本資料の施行日は2026年7月24日であり、コンプライアンス対応の主な責任はアクワイアラおよびPFに求められると考えられます。

現時点では詳細な要件について確認が必要な部分もありますが、今後の対応準備に向けて、早期に情報を共有することが重要であると考えています。

不正利用は「Fraud」から「Scam」へ進化

「当選しました!あと一歩で完了です!」や「無料トライアルのために情報を入力してください」といった内容の1ページ型投稿は、ソーシャルメディア上で日常的に見られるようになり、多くの詐欺への入り口となっています。国家警察庁の「165詐欺防止ダッシュボード」の統計によると、毎月数万件規模の詐欺被害が報告され、金銭的被害額は数十億規模に達しています。

さらに重要なのは、これらの多くが従来型の不正なクレジットカード利用ではないという点です。むしろ、消費者自身が「自発的に」送金や支払いを行ってしまうケースが大半を占めています。

最近、Business NextのインタビューでVisaのアジア太平洋地域リスク責任者は、世界的な不正リスクの状況が「Unauthorized Fraud(不正利用)」から「Authorized Scam(利用者承認型詐欺)」へと変化していると指摘しました。被害者自身が誤った情報に誘導され、手動で決済を承認してしまうため、銀行や規制当局にとって責任範囲の特定がより困難になっています。

利用者承認型詐欺によって発生した資金は、最終的に一見すると正常な加盟店アカウントへ流入します。これらの加盟店や取引では、従来型の不正利用レポートが発生するケースは少ない一方で、異常に高い返金率、チャージバック、そして不自然な加盟店行動パターンが確認されることがあります。

そのため、カードネットワークにおける防御アプローチも変化しています。盗難カードの追跡から、資金を受け取る加盟店の監視へと重点が移行しています。

MastercardのGLB 12772も、まさにこの考え方に基づいており、「返金+チャージバック合算比率」を活用して詐欺リスクの高い加盟店を特定します。この対応の実行主体となるのは、アクワイアラおよびPFです。

主要要件:5%、500件の取引、30日間

調査結果によると、今回の主要なトリガー条件は以下の通りです。加盟店の「返金+チャージバック」合算比率が、ローリング30日間(現在日を基準として過去30日間を遡って算出)における取引件数の5%を超過し、かつ最低500件以上の取引が存在する場合、対象となります。

つまり、500件の取引のうち、わずか25件で問題が発生した場合でも、この基準に達することになります。この条件に該当した場合、アクワイアラまたはPFは72時間以内に調査を開始する必要があります。

調査の結果、詐欺加盟店であることが確認された場合、MastercardおよびMaestroの利用受付は即時停止する必要があるとされています。警告通知や猶予期間は設けられないと報告されています。

また、本基準では返金も分子に含まれる点が重要です。これは、チャージバックのみを対象とする従来のECPプログラムとは異なります。さらに、チャージバックは申立てが行われた時点でカウントされ、後日加盟店側が紛争に勝った場合でも、通常は集計から除外されないと考えられます。

実際の計算方法や詳細な判定ルールについては、原文書およびご利用のアクワイアラから提供される正式な指示をご確認ください。

Figure 1 | GLB 12772 72-Hour Investigation Workflow

図1|GLB 12772に基づく72時間以内の調査ワークフロー (追加のトリガー条件:認証率低下、GRIPレター、MMSPアラートなど)

5%という基準値だけがトリガー条件ではありません。同文書では、その他の判定条件として以下の項目も挙げられているとされています。認証成功率の急激な低下(72時間以内に最低25件の取引があり、承認率が50ポイント以上低下、または30%未満に低下した場合)、GRIP調査レターの受領、およびMMSPによる詐欺アラートです。

さらに、アクワイアラはFLD(Fraud and Loss Database:不正・損失データベース)を利用し、新たに追加された詐欺リスク加盟店について日次確認を実施する必要があります。

また、Mastercardなどのカードネットワークは、承認処理時のリスク判断を支援するため、イシュア向けにMerchant Scam & Risk Indicator(MSRI)などのサービスを提供しています。加えて、イシュア側のリスク管理システムが、カード会員からの詐欺報告などをもとに特定の加盟店を高リスクとして判定している場合もあります。

その結果、対象加盟店の決済承認率が低下する可能性があります。そのため、アクワイアラまたはPFが加盟店の認証承認率の大幅な低下を検知した場合、その加盟店がすでにMSRIなどのリスク情報に登録されている可能性を示唆します。したがって、認証率の急激な低下も、重要な監視トリガーの一つとなります。

PF(ペイメントファシリテーター)への注意事項

現在入手可能な複数の情報源に基づくと、GLB 12772における対応義務を負う主体は、加盟店自身ではなく、アクワイアラおよびPF(ペイメントファシリテーター)であると考えられます。

この理解が正しい場合、貴社の管理下にあるいずれかのサブマーチャントがトリガー条件に該当した時点で、72時間以内の調査対応責任は貴社側に発生します。

調査の実施を怠った場合や、必要な利用停止措置が遅れた場合、Mastercardは対応責任を貴社に求める可能性があります。つまり、加盟店のリスク比率は、そのまま貴社のコンプライアンスリスクにつながることになります。

以下では、調査対象となる可能性が高い加盟店のタイプをいくつか紹介します。

■ 新規加盟店 (< 6 カ月)
処理実績が6か月未満の加盟店は、最も厳格な審査の対象となります。また、加盟店登録前には、Webサイトのスキャンを完了することが求められます(2026年1月より適用予定)。
■ 返金率の高い業界
デジタル商品、オンライン講座、サブスクリプションサービス、無料トライアル後の有料化モデルでは、返金が頻繁に発生するため、5%の基準値に容易に達する可能性があります。
■ 越境EC/購買代行業者
消費者が請求明細を「認識できない」と申告する可能性が高いため、必然的にチャージバックや不正報告が発生しやすい傾向があります。
■ 請求明細表示の不整合
請求明細の表示名がWebサイト上のブランド名と一致しない場合、消費者が直接チャージバックを申し立てる主な要因となります。

図2|貴社プラットフォーム上で調査対象となる可能性が高い4種類のサブマーチャント

今から始めるべき準備と対応策

複数の情報源から確認した規制動向を踏まえ、まず優先して取り組むべき実行項目は、取引の正当性を監視することです。その後、適切な評価を実施し、サブマーチャントの取引が継続的に管理下に置かれ、リスクの限界ラインを超えないようにすることが重要です。以下に、推奨される準備対応事項を示します:

  1. サブマーチャント向け「返金+チャージバック」確認機能またはAPIの提供(重要)
    多くの加盟店は、返金とチャージバックを別々に管理しており、「返金+チャージバック合算5%」という判定基準を十分に認識していません。 そのため、サブマーチャント自身がローリング30日間の合算比率をリアルタイムで確認できる機能(および5%基準までどの程度近づいているかを確認できる機能)を提供することは、最も低コストかつ直接的にリスクを事前対応へ移行させる方法です。加盟店自身がリスク状況を把握できれば、PF側による利用停止措置を待つのではなく、加盟店自らが早期に改善対応を開始できます。
  2. プラットフォーム側で30日間ローリング監視と内部警告基準を設定
    すべての加盟店を対象に、30日間のローリングウィンドウで「返金+チャージバック」の合算比率を算出し、5%到達前の内部警告閾値(例:3.5%)を設定します。この警告を早期に発動することで、72時間以内の調査義務が開始される前に、加盟店への事前指導やリスク低減対応を実施することが可能になります。
  3. 2時間以内の調査SOPおよび証跡取得チェックリストの策定
    期限内に、以下の対応を完了する必要があります:取引記録の取得、返金状況の確認、チャージバック関連資料の収集、Webサイトコンテンツの確認、決済明細上の請求者名の確認、ならびに加盟店とのコミュニケーションログの取得です。また、調査実施の証跡として、タイムスタンプ付きの記録を適切に保存する必要があります。期限内の対応を確実に実施するため、あらかじめ調査ワークフローや必要な報告フォームを整備しておくことが重要です。
  4. 新規加盟店登録プロセスの見直し(2026年1月適用予定)
    解釈によると、新規加盟店については、初回取引が発生する前にWebサイトスキャンを完了する必要があり、そのスキャンはMastercard認定MMSPによって実施、またはMMSPとの共同実施が求められるとされています。そのため、現在利用しているMMSPとの連携体制、およびスキャン対象範囲が十分であるかを事前に確認することを推奨します。
  5. 異常な認証率をアラート条件に組み込む
    単一加盟店における72時間以内の承認率の急激な低下は、カードテスト攻撃やソーシャルメディア等での詐欺報告が発生している可能性を示す、初期の重要なシグナルとなることがあります。また、これは今回の新ルールにおける公式なトリガー条件の一つとして位置付けられています。
  6. サブマーチャント契約条項の更新
    契約書には、調査協力義務、データ提供期限、即時契約解除に関する条項を盛り込み、72時間以内に必要な対応を実施できるよう、契約上の根拠を確保してください。
  7. アクワイアラへGLB 12772原文書の提供を依頼
    公開されている情報は、二次情報源に基づくものです。部分返金のカウント方法や500件の取引の正確な定義など、具体的な実装要件については、必ず正式な原文書およびご利用のアクワイアラから提供される実装ガイドラインをご確認ください。

参照: Mastercard文書 GLB 12772(会員限定資料、アクワイアラおよびペイメントファシリテーター向け)。本記事で参照している各種パラメータは、Mastercard認定MMSPであるAustremeの公開情報(austreme.com)および複数の決済リスク管理企業による共通見解・解釈に基づいています。 また、不正リスク動向に関する背景情報は、Visaアジア太平洋地域リスク責任者へのBusiness Next(bnext.com.tw)のインタビュー記事を参考にしています。 本記事はコンプライアンスアラートを目的とした情報提供であり、具体的な条項や適用要件については、必ずMastercardの正式文書をご確認ください。

ASVスキャンが失敗し続ける理由:CVSSのしきい値、誤検知&対処すべきポイント

ASVスキャンが失敗し続ける理由:CVSSのしきい値、誤検知 & 対処すべきポイント

ほとんどのASVスキャンの失敗は、実際の脆弱性が原因ではありません。プロセスの仕組み、しきい値の位置、出力結果の正しい解釈、そしてスキャナーが誤った情報を含むバージョン文字列を読み取ってしまう場合の影響を正しく理解していないことによって発生しています。

ASV — Approved Scanning Vendor, PCI Security Standards Council(PCI SSC)によって認定されたベンダーは、 PCI DSS 要件11.3.2で求められる外部脆弱性スキャンを実施します。コンプライアンスプログラムを失敗に導く要因の中でも、特に多い「3つの現実」が存在します。

1. CVSS 4.0のしきい値は想像よりも低い

PCI DSS v4.0.1では、外部ASVスキャンの合否判定におけるカットオフはCVSSスコア4.0と定められています。これは「Medium(中程度)」の下限にあたり、「High」や「Critical」ではありません。インターネットに公開され、かつカード会員データ環境(CDE)に接続されているホスト上で、CVSS 4.0の指摘が1件でも存在すると、そのスキャン全体は無効となり、コンプライアンスの検証は不合格となります。修正対応および再スキャンが完了するまで、認証は進めることができません。

PCI ASVスキャン — CVSS合否判定基準
CVSS 範囲 重大度 ASV スキャン結果
0.0 – 3.9 Low / None Pass ✓
4.0 – 6.9 Medium Fail ✗
7.0 – 8.9 High Fail ✗
9.0 – 10.0 Critical Fail ✗

「Medium(中程度)」という表現は、対応が任意であるかのように聞こえるかもしれません。しかし、現行基準ではそうではありません。1件でも該当すると、四半期ごとの脆弱性スキャンサイクル全体が停止してしまいます。

重要なポイントとして、この固定されたCVSS 4.0のしきい値は、外部ASVスキャン(Requirement 11.3.2)に適用されます。一方、Requirement 11.3.1に基づく内部脆弱性スキャンでは、Requirement 6.3.1で定義された自社のリスク評価手法に従って基準を設定します。 つまり、内部スキャンのしきい値は自社で定義できますが、外部ASVスキャンの基準は変更できません。

2. ASVスキャン結果がクリーンでも、QSA提出用レポートとしてそのまま通用するわけではありません

これは、私たちがFintech業界で最も多く目にするギャップの一つです。企業がスキャンツールを実行し、クリーンな結果を得たことで対応完了だと判断してしまうものの、実際には検証段階でQSAからレポート全体を差し戻されてしまうケースです。

問題は単純です。自動化されたスキャナーは生データを生成するだけであり、QSAが求めているのはコンプライアンスとして説明可能な証跡です。この2つは同じものではありません。

1回のスキャンでは数十件の指摘が返されることがあり、その多くはバナーグラビングWAFの干渉、またはバージョン検出の誤りによる誤検知です。これらは自動的にクリーンアップされることはありません。PCI DSS v4.0.1のもとでは、ASVレポートにおいてすべての指摘事項を優先順位付けし、すべての誤検知を適切に文書化、さらにCVSS 4.0以上の脆弱性については修正するか、正式に異議申立てを行う必要があります。

コンサルタントによる精査がない場合、フィルタリングされていない指摘事項がそのままエンジニアリングチームに渡されてしまいます。その結果、チームはクロスチェックや再テストを繰り返し、最終的にはその半分がそもそも対応すべき項目ではなかったと気づくことになります。ノイズにより、数週間の工数が失われてしまいます。

3. バックポートの罠:なぜASVスキャンは誤検知を生むのか

以下は、なぜ手動による精査が重要なのかを示す最も一般的な例です。

Ubuntuホストのバナーには OpenSSH 8.2 と表示されています。スキャナーはこれを基に CVE-2023-38408 と照合し、バージョン文字列との一致から自動的に失敗としてフラグ付けします。しかし実際には、その修正はすでにディストリビューションの8.2パッケージにバックポートされており、ホスト自体はパッチ適用済みです。ただしスキャナーはその事実を認識できません。

ASVスキャンはバナーグラビングに依存しており、サービスが提示するバージョン文字列を読み取り、それをCVEデータベースと照合します。そのため、ディストリビューションがどのパッチをバックポートしているかを把握する手段がありません。 RHEL、Debian、Ubuntuはいずれもこのバックポート方式を広く採用しています。パッケージのバージョン自体は変わらない一方で、実際の脆弱性はすでに修正されている場合があります。

正しい対応は、その指摘を無視することではなく、適切に異議申し立てを行い、証拠を収集します。例えば、インストール済みパッケージのバージョン(dpkg -lrpm -q)、バックポートを確認できるベンダーのセキュリティアドバイザリ、そして実際に適用されているパッチ済みのバージョン情報です。 それらを明確な説明とともに文書化し、ASVに提出します。

ただし、すべてを異議申し立てするべきではありません。ASVは、毎四半期30件以上の指摘をまとめて異議申し立てする企業の傾向を認識しています。修正できるものは修正し、確実な証拠に裏付けられた真の誤検知のみを慎重に異議申し立てすべきです。

結論

「Medium」は軽視できるスコアではありません。クリーンな結果は完成報告ではありません。バージョン情報が脆弱性を意味しない場合もあります。この3点の誤解が、実際のセキュリティ問題そのものよりも多くのASVスキャン失敗の原因になっています。 これら3つのギャップは、本来検出すべき実際のセキュリティ問題よりも多くのASVスキャンサイクル失敗の原因となっています。

FAQ

PCI ASVスキャンで不合格になるCVSSスコアはいくつですか?

 PCI DSS v4.0.1では、外部脆弱性スキャンにおいてCVSSスコア4.0以上の脆弱性(Mediumレベル:4.0〜6.9を含む)が存在する場合、ASVスキャンは自動的に不合格となります。コンプライアンスが有効と認められるためには、該当箇所を修正し、再スキャンを実施する必要があります。

ASVスキャンでの誤検知に対して異議申し立てを行うことはできますか?

はい。ある指摘が誤検知である場合、例えばバナーグラビングによって誤って識別されたバックポート済みパッチなどが該当します。その場合は、インストール済みパッケージのバージョン情報、ベンダーのセキュリティアドバイザリ、設定情報などの証拠をASVに提出することができます。 ASVは提出された内容を精査し、誤検知であることが確認された場合には再分類を行います。

ASVスキャンと内部脆弱性スキャンの違いは何ですか?

外部ASVスキャン(Requirement 11.3.2)は、CVSS 4.0という固定の合否基準を用い、PCI SSC認定のApproved Scanning Vendorによって実施されます。 一方、内部脆弱性スキャン(Requirement 11.3.1)は、Requirement 6.3.1に基づき組織独自のリスク評価手法に従って実施され、しきい値は社内で定義されます。

安律国際は、QSAの期待に沿ったASVレポートを通じて、企業の継続的なコンプライアンス維持を支援します。スキャンの初期仕分けから異議申し立て対応まで、プロセス全体をサポートし、7〜10営業日以内にレポートをお届けします。

ASVサービスの詳細を見る→

安律国際、 PCIDSS公認ASVに正式認定!

📢安律国際、 PCIDSS公認ASVに正式認定!

🌏アジア太平洋地域で、4つのPCI認証を保有する数少ない
  コンプライアンス企業に

このたび、安律国際(Secure Vectors Technologies Inc.)は、 PCI SSCにより正式に PCI DSS 公認ASV として認定されました。これにより、より信頼性の高い業界水準の脆弱性スキャンサービスを提供してまいります。

PCI DSS、3DS、および PIN Security は、決済カード業界における最も重要な3つのセキュリティ基準です。

当社は、ガバナンス、プロセス管理、技術的セキュリティの各領域を網羅し、真の「ワンストップ」PCIコンプライアンスソリューションをお客様に提供しています。

🔍ASV:脆弱性スキャンとコンプライアンスのゴールドスタンダード

ASV は単なる脆弱性スキャンではなく、PCI セキュリティ基準評議会(PCI SSC)により認定された包括的な評価サービスです。
PCI DSS の要件に従い、カード保有者データを保管、処理、または伝送するすべての事業者は、四半期ごとに脆弱性スキャン報告書を提出する必要があります。
PCI SSC は、対象となるすべての金融機関や決済事業者に対して、認定スキャン業者(ASV)を利用してスキャンを実施し、公式かつ検証済みの報告書を作成することを義務付けています。
ASV 認定を取得するには、以下の 3 つの重要要件を満たす必要があります:

1️⃣ スキャンツール

ASV サービスの脆弱性検出手法(手動手順、ワークフロー、技術ツールを含む)は、PCI SSC の基準に従って既知のすべての脆弱性を網羅的に特定する必要があります。また、テストベッドによるスキャンと分析を 18時間以内 に完了しなければなりません。
2️⃣ 実行チーム
スキャンを実施するエンジニアおよびサービスマネージャーは、毎年 PCI SSC の専門試験に合格する必要があります。これにより、知識やサービスプロセスが PCI SSC の基準を満たしていることが保証されます。
3️⃣ 報告プロセス
公式に監査されており、結果の正確な解釈、誤検知(false positives)の適切な処理、一貫性と追跡可能性のある報告フォーマットの遵守が確保されています。
最終的に PCI SSC による審査と承認を経て初めて、企業およびそのスキャンソリューションは正式な ASV 認定を取得できます。このプロセスでは、ASV 提供者およびそのソリューションが以下の点で評価されます:

🔎検出範囲
複数のプロトコル層にわたる脆弱性を網羅的に検出できる能力

🎯評価の正確性
誤検知(false positives)と実際のリスクを正確に区別する能力

📋 報告の厳密性
監査対応可能なコンプライアンス証跡を提供できる能力

ASV:決済業界で世界的に信頼される存在

📅 2025年10月、Secure Vectors Technologies Inc. は正式に PCI SSC の審査を通過し、認定スキャン業者(ASV) として登録されました。
この認定は以下を意味します:
  • 業界での認知
    金融・決済分野の PCI DSS コンプライアンス監査では、ASV によるスキャン報告書のみが正式な証跡として認められます
  • 検証済みの技術・チーム・プロセス
    技術、チームプロセスのすべての側面が PCI SSC により検証済み です。
  • 決済業界で信頼されるベンチマーク
    アジア太平洋地域で QSA × 3DS × PIN Security × ASV 認証を保有する数少ないコンサルティング企業のひとつとして、弊社は企業が複数の規制枠組みにわたり継続的にコンプライアンスを維持できるよう支援します
  • 今後は、この達成を基盤として、金融・決済機関への ASV スキャンやコンプライアンス報告の支援にとどまらず、業界や地域を超えた外部ドメインの脆弱性スキャン、報告、および関連サービスの提供 を目指します。これにより、企業がコンプライアンスを ビジネス成長の優位性に変える サポートを行ってまいります。
ASV 脆弱性スキャンの専門サポートは、ぜひお問い合わせください
👉 お問い合わせはこちらから

FAQ

Q1: PCI DSS ASVとは?

ASV(認定スキャン業者) とは、PCI セキュリティ基準評議会(PCI SSC)に認定された外部脆弱性スキャンサービス であり、そのスキャンソリューションは PCI SSC により検証・承認されています。PCI DSS の要件 11.3.2 に基づき、組織は 四半期ごとに ASV による外部スキャンを実施 し、合格した報告書を受け取ることで、ほぼ 12か月分のコンプライアンス証跡 を維持する必要があります。

Q2:ASVと通常のスキャンツールの違いは?

ASV は単なるスキャンツールではなく、PCI SSC により認定された 包括的なスキャンソリューション です。
そのツール、実行チーム、手順、報告ワークフローはすべて公式のテストと監査を通過する必要があります。
また、PCI に認定された ASV のスキャン報告書のみが、PCI DSS コンプライアンス監査の正式な証拠として使用でき、金融・決済業界で広く信頼されています。

マイクロソフト、大規模セキュリティ更新を実施 130件の脆弱性に対応!

マイクロソフト、7月の「Patch Tuesday」で130件の脆弱性を修正

SQL ServerにおけるPCI DSS関連リスクも判明

 

2025年7月9日、マイクロソフトは今月の定例更新「Patch Tuesday」を公開し、合計130件のセキュリティ脆弱性を修正しました。このうち10件は「緊急(Critical)」と評価されています。更新対象には、SQL Server、Windows、Office(Word、PowerPoint、Excel)など、主要なマイクロソフト製品が含まれます。

■ PCI DSSにも関連する重要な脆弱性

今回の修正の中で特に注目すべきは、Microsoft SQL Server における情報漏洩の脆弱性(CVE-2025-49719、CVSSスコア:7.5)です。

この脆弱性により、攻撃者が初期化されていないメモリを読み取れる可能性があり、パスワードや暗号鍵などの機密情報が漏洩するリスクが指摘されています。

Rapid7 の Principal Software Engineer である Adam Barnett 氏は、

攻撃者がすぐに意味のあるデータを取得できるわけではないが、熟練した操作により暗号鍵など重要情報を抽出できる可能性がある。

と警告しています。

また、Action1 の社長 Mike Walters 氏は、

脆弱性の原因は SQL Server のメモリ管理における入力検証の不備にあると考えられる。これにより認証情報、接続文字列、その他の機密データが漏洩する可能性がある。

と指摘しました。影響範囲は SQL Server エンジンおよび OLE DB ドライバーを利用するアプリケーションに及びます。

■ セキュリティ専門家からの警告

セキュリティ専門家は以下を強く推奨しています:

  • システム管理者およびITチームは、直ちに今回の更新プログラムを適用すること
  • 特に Microsoft SQL Server を運用している組織においては、大規模悪用のリスクを未然に防ぐための早急な対応が必要

 

出典

#Microsoft #CyberSecurity #PatchTuesday #InfoSec #VulnerabilityManagement #PCI #SQLServer #WindowsSecurity


 

【Secure Vectorsのセキュリティ豆知識】

📌 CVSSとは?

CVSS とは Common Vulnerability Scoring System(共通脆弱性評価システム) の略称です。これは、報告された脆弱性を 標準化された、再現性のある方法で評価・ランク付けする仕組み を指します。このスコアによって、組織はさまざまなセキュリティリスクへの対応優先度を決定することができます。

CVSS は、脆弱性の重大度に応じて 0 から 10 までのスコア を算出します。
10 が最も深刻であり、以下のような要素に基づいて評価されます:

  • 脆弱性がどれだけ容易に悪用できるか
  • 機密性・完全性・可用性への影響度
  • 攻撃の複雑さ

シンガポール・フィンテック・イノベーションセミナー

シンガポール・フィンテック・イノベーションセミナー

Security and Compliance Automation

世界のデジタルファイナンスは、今まさに多角的な発展、新興技術、イノベーションビジネスの進化を経験しつつあり、市場や市場への新規参入者の急速な成長を牽引し続けています。これに伴って生じている情報セキュリティの脆弱性、ハッキング、詐欺の手法は、デジタルファイナンスに関わるすべての事業者にとって大きな課題となっています。 これらの相次ぐ課題に対応するため、監督官庁、カードブランド、業界団体等は常に法令、基準、準拠要件をアップデートしています。事業者の規模にかかわらず、要件に確実に準拠することは、並大抵ではない挑戦です。しかし、セキュリティとコンプライアンスはこれ以上先延ばしにはできません。要件を一つでも軽視したり、要件について手を抜いたりすれば、業界から取り残されるばかりか、規定違反で巨額の罰金を科されることにもなりかねません。 2023フィンテック・イノベーションセミナーでは、金融決済業のトレンド、最新の準拠要件、セキュリティ基準の変化をいち早く解説するほか、万全の情報セキュリティとコンプライアンスの自動化を実現するための新しい概念とソリューションを詳しくご紹介します。ぜひご参加ください。 日時:2023年11月14日 14:00~17:00 場所:サンズ エキスポ & コンベンションセンター3階(3011)Begonia Junior Ballroom 住所:10 Bayfront Ave., Singapore 018953

Topic 1:Innovation of New Payments and Compliace Automation 

Speaker:Vincent Huang – PCI DSS QSA, Secure Vectors Information Technology Inc.

Topic 2:Mitigate open source security with DevSecOps

Speaker:Ding Sun – Head Engineering, Scantist Pte. Ltd.

Topic 3:PIN Security – New Standard TR-31 (Key Blocks) 

Speaker:Lai Seow Yong – APAC Technical Pre-sales Manager,
             Utimaco Management GmbH

備考:

  • イベントでは記録のため写真および動画の撮影を行います。撮影した写真および動画は、後日イベント専用ページに掲載するほか、プロモーションに使用します。
  • 規定のない事項については、主催者が調整、最終的な修正、変更、イベントの解釈、イベントの中止の権利を有します。修正後の内容はイベント専用ページに掲載し、個別の通知はいたしません。あしからずご了承ください。

金融業のクラウド移行が大幅緩和!9月に新法施行、今後のチャンスと課題は?

2022年4月からBINコードが上8桁に。システム変更の準備は万全ですか?

2022年4月に入ってから、国際カードブランドは決済事業者に対し、新たに導入された8桁のBIN(銀行識別番号、Bank Identification Number)にシステムを対応させるよう、次々と要求しています。カード決済に関わる川上・川下の企業はすでに、システムや取引データの処理、さらにはカード売上票に印刷されるカード番号の形式までを8桁のBINに対応させるよう求める銀行からの通知を受け取ったことでしょう。

BINの形式変更は、クレジットカードを取り扱う業界にどのような影響を与えるのでしょうか?

まず、発行済みの6桁のBINコードは引き続き使用できますが、今月(2022年4月)以降に新たに発行されるカードのBINは基本的に8桁となります。今のところ、カード番号は従来通り16桁(American ExpressとDiscoverは15桁以下)のままなので、イシュアやカード発行システムへの影響はそれほど大きくはないでしょう。しかし、これまでカード番号の7桁目と8桁目をカードのレベル、種類などに使用してきた方式は、8桁のBINに対応して変更する必要があります。

しかしながら、当面は6桁と8桁のBINが取引システムやネットワークに併存することになります。そのため、ATMシステム、取引システム、決済システムといったBINを利用して取引のルーティング(Routing、BINでイシュアを識別)を行うシステムや、決済事業者が現在自社カード取引のルーティング(Routing、BINに基づいて自社カードの決済システムに送信)に使用している機能は、6桁と8桁の併存段階で起きるエラーを防ぐため、8桁のBINに対応しなければなりません。

次に、カード会員データを保存する際に、データ保護措置としてトランケーション(Truncation)技術を採用している場合ですが、今年1月、PCI SSC(ペイメントカード業界セキュリティ基準委員会、Payment Card Industry Security Standards Council)から、各カードブランドで許容可能な新しいトランケーション形式が正式に発表されました。これも、皆さんが関心を持たれている話題でしょう。

新しいBINコードに対応して、保存形式も変更する必要があります。6桁と8桁が併存することを考慮すると、画面への表示やトランケーション処理後のカード番号の保存にどう対応したらよいのでしょうか?

2021年2月、PCI SSCは「8桁のBINの使用を開始する場合、PAN(プライマリアカウント番号)のマスキングとトランケーションに関するPCI DSSの要件にどう対応するかについてのFAQ」を発表しました(https://www.pcisecuritystandards.org/faqs FAQ #1492を参照ください)。以下はその概要です。

1. マスキング:PCI DSS要件3.3では、一般的な状況においては、PANの先頭6桁と末尾4桁のみ表示するとされています。

先頭6桁と末尾4桁より多く(たとえば先頭8桁と末尾4桁)を表示するためには、正当なビジネスニーズがあり、かつ取扱者(または役割)、理由が記載された文書を作成し、会社の上級管理者の許可を得る必要があります。

2.トランケーション:PCI DSS要件3.4では、カード番号を保存する際に読み取り不可能(Rendered Unreadable)な形にしなければならないとされています。その方法の一つがトランケーション(Truncation)です。PCI DSSのガイダンスでは一般的なトランケーション形式を先頭6桁と末尾4桁としていますが、カードブランドによってトランケーション形式に関する規定が異なるため、この文章(FAQ #1492)内に別途補足説明としてFAQ番号1091「許容可能なカード番号トランケーション形式」が附されています(2022年1月更新)。

今年1月以降の許容可能なトランケーション形式は、次の通りです。

カード番号/BINの長さ カードブランド 許容可能なトランケーション形式
16桁のカード番号

6桁または8桁

Discover

JCB

Mastercard

UnionPay

Visa

少なくとも4桁を削除すること

保存可能な最大桁数:先頭8桁+他の4桁

15桁のカード番号 American Express 少なくとも5桁を削除すること

保存可能な最大桁数:先頭6桁 + 末尾4桁

15桁未満のカード番号 Discover 保持可能な最大桁数:先頭6桁+他の4桁

出典:https://www.pcisecuritystandards.org/faqsFAQ番号1091

今回の更新により、6桁のBIN8桁のBINとの間におけるトランケーション形式の区別がなくなったことに注意が必要です。まとめると、

  1. VISA、Mastercard、JCB、Discover、UnionPay(銀聯)は、16桁のカード番号の先頭8桁 + 他の4桁の形式を許容
  2. American Expressは先頭6桁 + 末尾4桁の形式のみを許容
  3. 15桁未満のDiscoverは、削除する桁数にかかわらず、すべて先頭6桁 + 他の4桁の形式を許容

同時に、カードブランドでは、これらのトランケーション形式は「許容可能」ではあるが、「必要最小限のデータのみ保持する」という観点から、形式の変更に合わせて直ちに自社のシステムを変更する必要はないとしています。

なお、トランケーション関連のセキュリティ保護については、以下の事項にも注意してください。

  1. PCI DSSでは、SHAハッシュ方式を同時に使用するシステムでは、先頭6桁 + 末尾4桁を保存する場合、先頭8桁 + 末尾4桁を保存する場合のいずれにおいても注意が必要だとしている。トランケーション形式とSHA形式のデータを同時に保存した時、特に先頭8桁 + 末尾4桁の形式の場合、4桁しか削除されないことになるため、SHA形式で同時に保存すると、正確なカード番号を割り出せてしまう確率がより高くなる。
  2. 先頭8桁 + 他の4桁のトランケーション形式を使用する場合、MOD-10の公式に適合するのは残り1000件のデータだけである。つまり、この1000件のうち少なくとも1件は真のカード番号ということになる。したがって、カード番号を再現されたり、算出されたりするリスクを下げるため、データベースへのアクセス制御に関しては、より厳しい制御や内容のチェックが必要となる。

参考資料:https://www.pcisecuritystandards.org/faqs

  • FAQ No. 1492: How can an entity meet PCI DSS requirements for PAN masking and truncation if it has migrated to 8-digit BINs? (by Feb. 2021)
  • FAQ No. 1091: What are acceptable formats for truncation of primary account numbers? (by Jan. 2022)

Bryan Cheng

SecureVectors PCI認定コンプライアンスQSAおよびコンサルタント - PCI QSA and Senior Consultant
  • Payment Card Industry Security, IT Security Management, Cloud Service Management
  • 專業認證:PCI DSS QSA, CISSP, ISO27001 LA, BS10012 LA, MCSE, MCITP, TUViT Privacy Protection Consultant

PCI DSS 認証取得のプロセスおよび費用

目錄

PCI DSSについて

Payment Card Industry Data Security Standards(略称PCI DSS)は、主要国際カードブランド数社がカ

ード会員データの安全な

取り扱いのために策定した、カード業界共通のセキュリティ基準であり、適用対象はカード会員データを保存、処理、伝送する事業者全般に渡ります。これらの国際ブランドのカードを取り扱う加盟店(Merchant)やサービスプロバイダ(Service Provider)はいずれも、規模や取引量にかかわらず、PCI DSSに則ってカード会員データを保護する必要があります。
PCI DSS認証のセキュリティ基準を策定、管理しているのはPCI SSC(Payment Card Industry Security Standard Council、PCIセキュリティ基準審議会)で、創設メンバーのAmerican Express、Discover、JCB、MasterCard、VISAおよび戦略的メンバーのUnionPay(銀聯)で組織されています。

PCI DSS認証レベルについて

PCI DSS認証は通常、PCI DSS審査(PCI DSS Assessment)と呼ばれています。加盟店(Merchant)やサービスプロバイダ(Service Providers)は、カードブランドによって多少違いはあるものの、総じてレベル1~4に分けられ、レベルに応じたセキュリティ対策が要求されます。

カードブランドによってレベルの規定は若干異なりますが、例としてVISAの規定を紹介します。

  • 加盟店レベル

  • サービスプロバイダレベル

レベル1の加盟店およびサービスプロバイダは、PCI DSSのQSA(Qualified Security Assessor、認定セキュリティ評価者)の訪問審査を受け、報告書を受け取ります。レベル2~4の加盟店およびレベル2のサービスプロバイダは、PCI DSS SAQ(自己問診票)を使って自己評価するか、もしくはQSAに評価を依頼します。
自社のレベルや適用されるSAQのタイプは、アクワイアラに確認しましょう。

PCI DSS認証取得にかかる期間

一般にPCI DSS認定取得までの流れは、大きく次の段階に分けられます。

PCI DSS Compliance Timeline_JA

準備開始からコンサルティング、審査実施までの一連の作業にかかる時間は、事業者の準備状況やシステム、運用プロセスの複雑さにもよりますが、通常3~5か月ほどです。

PCI DSS関連費用

1. システム関連費用

PCI DSSでは強固なセキュリティを求めているため、システム関連の費用が増加します。たとえば、要件2.2.3では「1つのシステムコンポーネントに存在する主機能は1つだけ」(One Primary Function Per Server)としています。Webサーバ、アプリケーションサーバ、DBサーバなどの機能が1つのサーバに置かれている場合は、別々のサーバ(仮想サーバでもよい)に分けなければならないため、サーバの増設が必要になる可能性があります。あるいは、コンテナ化(Containerization)して切り離す必要があります。
なお、PCI DSSでは、DNSサーバ、NTPサーバ、FIMサーバ(File Integrity Management)、ログ解析サービスなどのセキュリティコンポーネントを実装するよう求めており、要件を満たすために機器の増設が必要となる可能性があります。

2. セキュリティ機器費用

PCI DSSのセキュリティ要件に対応するため、ファイアウォール、IPS、IDS、WAFといったセキュリティ機器の増設が必要になる可能性があります。

3. データ暗号化装置費用

PCI DSSはカード会員データを暗号化するよう求めています。高いセキュリティレベルと高い性能が求められる事業者では、HSM(ハードウェアセキュリティモジュール)を使用して、カード会員データを保存する際のセキュリティを確保しなければなりません。

4. トレーニング関連費用

PCI DSSでは、セキュリティ意識向上トレーニング(Awareness Training)、開発者向けトレーニング(Secure Coding Training)、インシデント対応計画(IRP:Incident Response Plan)の訓練など、従業員向けのトレーニングを実施するよう要求しています。なお、社内で脆弱性スキャン(Vulnerability Scan)やペネトレーションテスト(侵入テスト)を行う場合、社内のテスターに十分なセキュリティ技術トレーニングを受けさせる必要があり、その分、訓練費用も増加します。

5. テクニカルテスト費用

PCI DSSでは、以下の複数のテクニカルテストを定期的に実施するよう要求しています。

    • カード会員データのスキャン (Card Number Scanning)
    • コードレビュー (Code Review)
    • 内部脆弱性スキャン(Internal Vulnerability Scan)
    • 外部脆弱性スキャン (ASV, External Vulnerability Scan)
    • 内部ペネトレーションテスト (Internal Penetration Test)
    • 外部ペネトレーションテスト (External Penetration Test)
    • ワイヤレススキャン (Wireless Scan)

これらのテストのための費用が新たに発生します。

6. その他の費用

サービスプロバイダ(Service Provider)は、アクワイアラまたはカードブランドから、カードブランドのウェブサイトにプロバイダ登録するよう要求されます。たとえば、VISAのVISAレジストリ VISA 的 VISA SP Registry  やMasterCardのサービスプロバイダ登録などがあります。

中小規模のサービスプロバイダ(Service Provider)で、過去にPCI DSSに準拠したことがなければ、通常、次に挙げるような費用が新たに発生します。

PCI DSSの審査費用

これらの費用に加えて、PCI DSSの審査費用がかかります。この費用は、PCI DSS QSAによる審査と報告書作成にかかる時間によって決まります。また、審査に要する時間の目安は、以下の要素に関係しています。

• システムの複雑さ

サーバの数、システムで使用するOSの種類、システムにインストールされているコンポーネント(Component)の数。複数のOSが同時に使用され、また複数のセキュリティ構成がある場合は、テスト時のサンプリング(Sampling)が大幅に増加します。

• セキュリティ機器とネットワークセグメント

審査の対象となるセキュリティ機器の数。ファイアウォール、IPS、IDS、WAF、スイッチ、ルーター、SIEM、FIMなどのセキュリティ機器は、設定や更新状況、アクセス制御、ログなどを検査し、記録を保存する必要があります。そのため、セキュリティ機器の数が多いほど、ネットワークセグメントが複雑になり、審査に時間がかかります。

• 接続するアクワイアラやサービスプロバイダの数

接続するアクワイアラやサービスプロバイダの数が増えるほど、データフロー(Dataflows)が複雑になるため、検査に時間がかかります。

• データベース、カード会員データの保持と暗号化

カード会員データのデータフローが複雑になるほど、また保存するカード会員データの種類が増えるほど、暗号化やセキュリティ保護の要件が増え、審査項目も多くなります。

• 運用地点の数

店舗、サーバルーム、オフィスなどの運用地点数は、審査日数に直接影響します。たとえば、店舗やオフィスなど運用地点の数が多い銀行や通信会社などでは、サンプリングの必要数も増えます。なお、カード会員データを保管するバックアップサーバルームがある場合、通常これらも審査対象となります。

一般的に、PCI DSSの審査費用は地域によって異なります。これは、PCI SSCが各地域から徴収する年会費やQSAの給与が地域によって異なるためです。東南アジアで言うと、中小規模のサービスプロバイダが初めて審査を受ける場合、訪問審査(On-site Assessment)に3~5日、報告書作成に約1週間かかるため、交通費を除いた初回の認証費用は、新台湾ドル40~60万元ほどが相場となります。ただし、実際にかかる費用は、上述の複雑さなどを加味した正確な審査時間を元に計算されます。

Vincent Huang
セキュアベクターズ・インフォメーション・テクノロジーズ – PCI QSA・シニアコンサルタント – PCI QSA and Senior Consultant
  • IT Security Management, Payment Card Industry Security, Data Center Security and Cloud Security
  • 専門資格:PCI DSS QSA, PCI 3DS Assessor, PIN Security QPA, CISSP, CEH, NSPA, ISMS LA, ITSM LA, Certified CSA STAR Auditor, Europrise Technical Expert
Secure Vectors Information Technologies Inc.

セキュアベクターズ・インフォメーション・テクノロジーズ (SecureVectors Information Technologies Inc.) は、ペイメント業界のセキュリティ管理(テクニカルテスト、コンサルティング、認定審査等)を専門に支援する企業です。当社は、PCI DSSPCI 3DSPCI PIN Securityといったペイメントカード業界のセキュリティ基準とコンサルティングサービスを提供しています。アメリカ、イギリス、中国、日本、シンガポール、ベトナム、台湾などの地域に営業拠点を置き、認証(認定審査)、セキュリティ管理代行、準拠管理プラットフォーム、コンサルティングなど、準拠関連の製品やサービスを提供しています。

PCI DSS認証取得のプロセスと追加費用 | SecureVectors

PCI DSSは国際カードブランドがカード会員データのセキュリティを守るために共同で策定した業界の基準です。ここでは、PCI DSS認証取得に関わる加盟店やサービスプロバイダのレベル、準拠にかかる時間や流れ、新たに発生する費用、審査やコンサルティングの費用などを解説しており、PCI DSS準拠の要件や予算を素早く理解できる記事になっています。

*準拠サービスについての詳細は、 service@securevectors.comまでお気軽にお問い合わせください

PCI 3DS準拠への3ステップ

3Dセキュア認証(3-D Secure

加盟店(Merchant)のECプラットフォームにおいて、支払いにクレジットカードを使用する際、消費者(Consumer)がワンタイムパスワードを入力して3Dセキュア認証(3-D Secure)を完了しなければ取引は完了しません。これは、クレジットカード取引のセキュリティをより向上させる技術です。3Dセキュア認証サービスのプロセスは、3DSサーバ(3DSS)、3DSディレクトリサーバ(DS)、3DSアクセスコントロールサーバ(ACS)の3つのシステムコンポーネントで構成されています。

3Dセキュア認証サービスの提供者

3Dセキュア認証サービスのシステムコンポーネントには3DSS、DS、ACSがあり、それぞれ次の事業者が使用します。

  • 3DSSを使用するのは銀行(Bank)やアクワイアラ(Acquirer)であり、自社で3DSSを設置、管理しても、3DSソリューションを提供するサービスプロバイダ(ホスティングサービスプロバイダ)のサービスを利用してもかまいません。3DSSは加盟店に接続し、DS(カードブランド)との間で3Dセキュア認証メッセージのやりとりを行います。
  • DSはカードブランド(VISA、MasterCard、JCB、Discover、American Express)が所有し、3DSSとACS間における3Dセキュア認証データのやりとりの要となる場所です。
  • ACSを使用するのはイシュア(Issuer)です。3DSソリューションを提供するサービスプロバイダ(ホスティングサービスプロバイダ)のホスティングを受けることもできます。

これらのシステムコンポーネントは、EMVCoが策定した製品と機能の規格(EMV®3-D Secure-Protocol and Core Functions Specification v2.0)に合格しなければなりません。また、サービスプロバイダも、PCIセキュリティ基準審議会(PCI SSC)が策定したPCI 3DSコアセキュリティ基準(Security Requirements and Assessment Procedures for EMV®3-D Secure Core Components: ACS, DS and 3DS Server)に準拠し、3DSシステムの運用環境およびデータのセキュリティを確保しなければなりません。

PCI 3DS審査の準備

すべての3Dセキュアプロダクト(ACS、DS、3DSS)はEMVCoの製品テストに合格した上で、各カードブランド(VISA、MasterCard、JCB、Discover、American Express)の運用テストに合格してはじめて相互運用性(Interoperability)が保証されます。また、3Dセキュア製品の運用環境のセキュリティは、PCI SSCが策定したPCI 3DSコアセキュリティ基準の認定を取得する必要があります。

PCI 3DSの審査は、PCI SSCから認定を受けたQSAによって行われます。通常は、3Dセキュア製品がカードブランドの運用テストに合格し、アクワイアラや加盟店(Acquirers、Merchants)がPCI 3DSの審査に合格してはじめて、正式にオンラインで3Dセキュアサービスを運用することが許可されます。

PCI 3DSコアセキュリティ基準はPart1とPart2に分かれています。

  • Part1:3DSシステムの運用環境のセキュリティ要件(3DS Baseline Security Requirements)を定める
  • Part2:3DSシステムの運用そのもののシステムのセキュリティやデータのセキュリティ要件(3DS Security Requirements)を定める

なお、決済事業者やサービスプロバイダの使用する環境、または3Dセキュアシステムが運用される環境が、すでにPCI DSSの認証を受けており、PCI 3DSの運用に必要な対象範囲がPCI DSS認定審査の対象範囲と同一である(排除項目が存在しない)場合、PCI 3DSではPart2の要件にのみ対応すればよいとされています。

PCI 3DSの審査を受ける前に、次の3つの段階で準備を進めましょう

(1)   3Dセキュアデータの保存と保護に関する要件

処理される3Dセキュア取引データは、いずれもPCI 3DSの要件に準拠していなければなりません。したがって、決済事業者やサービスプロバイダは、既存の、または運用を計画している3Dセキュアシステムのデータフローやデータの保存方法がPCI 3DS Data Matrixのデータの保存と保護に関する各要件に準拠しているかどうか、チェックする必要があります。これには認証データ、鍵データ、暗号鍵(ACS、DSに適用)の保護と保存の規定が含まれます。準拠要件において保存が禁止されているデータは、システムの取引処理プロセスにおいて非保持が徹底される必要があります。ベンダが提供または設置に協力したシステムであっても、ベンダに3Dセキュアデータの取り扱い方法を確認しなければなりません。

(2)   手順および管理の準備と実施

PCI 3DSは、決済事業者やサービスプロバイダに対し、アクセス制御ポリシーやソフトウェア開発手順等の管理ポリシーおよび管理手順を定め、3Dセキュアサービスのセキュリティ管理をPCI 3DSに準拠させるよう求めています。また、PCI 3DSでは、運用上のリスクの存在を前提として、対応するセキュリティ対策と実施レベルを定めており、リスク評価結果、ハードウェア・ソフトウェア目録、ネットワーク構成図およびデータフロー図(Network Diagrams、Data Flow Diagrams)、各テストおよび実施記録など、管理に必須の文書や記録を作成し、保存するよう求めています。

(3)   準拠に必要なテクニカルテストの実施

PCI 3DSでは以下のテクニカルテストが求められています。

  • ソフトウェア・セキュリティテスト(Software Security Tests)
  • 四半期に1回の内部・外部脆弱性スキャン(Vulnerability Scans)
  • 毎年1回のペネトレーションテスト(侵入テスト)

これらのテストは、専門のテストプロバイダに委託しても、社内の専門技術者が行ってもかまいません。ただし、外部脆弱性スキャンは、PCI SSCから認定されたASVが行う必要があります。

PCI 3DS審査の実施

PCI 3DSの認定サービスプロバイダがPCI 3DS QSAです。リストはPCI SSCのウェブサイトで検索できます。セキュアベクターズは、現在アジア太平洋地域においてPCI 3DS審査サービスを提供している数少ないQSA企業の一つです。

審査作業は組織の規模や3Dセキュアシステムの実装方法によって異なります。一般に、審査前または審査開始段階でスコープ(対象範囲)を確認します。審査期間中は3~5日間かけてオンサイト評価(訪問審査)を実施し、さらにオフサイトで評価担当者のレポートとエビデンスをチェックします。審査完了後、QSA企業が準拠報告書(Report On Compliance、ROC)に署名し、審査を受けた事業者が準拠証明書(Attestation of Compliance、AOC)に署名すれば、認定となります。

PCI 3DSコアセキュリティ基準では毎年1回審査を受けるよう定めています。決済事業者やサービスプロバイダは、カードブランドやアクワイアラの求めに応じてAOCまたはROCを提出しなければならず、これにより、その年の審査が完了となります。


Max Tsai

PCI QSA and Senior Consultant

• Payment Card Industry Security, IT Security Management, Cloud Service Management
• 專業認證: PCI DSS QSA, CISSP, ISMS LA