マイクロソフト、大規模セキュリティ更新を実施 130件の脆弱性に対応!
/in Knowledge-jp, 最新情報
マイクロソフト、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 が最も深刻であり、以下のような要素に基づいて評価されます:
- 脆弱性がどれだけ容易に悪用できるか
- 機密性・完全性・可用性への影響度
- 攻撃の複雑さ
シンガポール・フィンテック・イノベーションセミナー
/0 Comments/in Events-jp, 最新情報シンガポール・フィンテック・イノベーションセミナー
Security and Compliance Automation
世界のデジタルファイナンスは、今まさに多角的な発展、新興技術、イノベーションビジネスの進化を経験しつつあり、市場や市場への新規参入者の急速な成長を牽引し続けています。これに伴って生じている情報セキュリティの脆弱性、ハッキング、詐欺の手法は、デジタルファイナンスに関わるすべての事業者にとって大きな課題となっています。 これらの相次ぐ課題に対応するため、監督官庁、カードブランド、業界団体等は常に法令、基準、準拠要件をアップデートしています。事業者の規模にかかわらず、要件に確実に準拠することは、並大抵ではない挑戦です。しかし、セキュリティとコンプライアンスはこれ以上先延ばしにはできません。要件を一つでも軽視したり、要件について手を抜いたりすれば、業界から取り残されるばかりか、規定違反で巨額の罰金を科されることにもなりかねません。 2023フィンテック・イノベーションセミナーでは、金融決済業のトレンド、最新の準拠要件、セキュリティ基準の変化をいち早く解説するほか、万全の情報セキュリティとコンプライアンスの自動化を実現するための新しい概念とソリューションを詳しくご紹介します。ぜひご参加ください。 日時:2023年11月14日 14:00~17:00 場所:サンズ エキスポ & コンベンションセンター3階(3011)Begonia Junior Ballroom 住所:10 Bayfront Ave., Singapore 018953Fintech Singapore – Media Report
Breaching the New Frontier in Payments Security and Compliance Automation – Fintech Singapore
備考:
- イベントでは記録のため写真および動画の撮影を行います。撮影した写真および動画は、後日イベント専用ページに掲載するほか、プロモーションに使用します。
- 規定のない事項については、主催者が調整、最終的な修正、変更、イベントの解釈、イベントの中止の権利を有します。修正後の内容はイベント専用ページに掲載し、個別の通知はいたしません。あしからずご了承ください。
2022年4月からBINコードが上8桁に。システム変更の準備は万全ですか?
/in Knowledge-jp, 最新情報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/faqs(FAQ番号1091)
今回の更新により、6桁のBINと8桁のBINとの間におけるトランケーション形式の区別がなくなったことに注意が必要です。まとめると、
- VISA、Mastercard、JCB、Discover、UnionPay(銀聯)は、16桁のカード番号の先頭8桁 + 他の4桁の形式を許容
- American Expressは先頭6桁 + 末尾4桁の形式のみを許容
- 15桁未満のDiscoverは、削除する桁数にかかわらず、すべて先頭6桁 + 他の4桁の形式を許容
同時に、カードブランドでは、これらのトランケーション形式は「許容可能」ではあるが、「必要最小限のデータのみ保持する」という観点から、形式の変更に合わせて直ちに自社のシステムを変更する必要はないとしています。
なお、トランケーション関連のセキュリティ保護については、以下の事項にも注意してください。
- PCI DSSでは、SHAハッシュ方式を同時に使用するシステムでは、先頭6桁 + 末尾4桁を保存する場合、先頭8桁 + 末尾4桁を保存する場合のいずれにおいても注意が必要だとしている。トランケーション形式とSHA形式のデータを同時に保存した時、特に先頭8桁 + 末尾4桁の形式の場合、4桁しか削除されないことになるため、SHA形式で同時に保存すると、正確なカード番号を割り出せてしまう確率がより高くなる。
- 先頭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
PCI DSS 認証取得のプロセスおよび費用
/0 Comments/in Knowledge-jp, 最新情報目錄
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認定取得までの流れは、大きく次の段階に分けられます。

準備開始からコンサルティング、審査実施までの一連の作業にかかる時間は、事業者の準備状況やシステム、運用プロセスの複雑さにもよりますが、通常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 DSS、PCI 3DS、PCI PIN Securityといったペイメントカード業界のセキュリティ基準とコンサルティングサービスを提供しています。アメリカ、イギリス、中国、日本、シンガポール、ベトナム、台湾などの地域に営業拠点を置き、認証(認定審査)、セキュリティ管理代行、準拠管理プラットフォーム、コンサルティングなど、準拠関連の製品やサービスを提供しています。
PCI DSS認証取得のプロセスと追加費用 | SecureVectors
PCI DSSは国際カードブランドがカード会員データのセキュリティを守るために共同で策定した業界の基準です。ここでは、PCI DSS認証取得に関わる加盟店やサービスプロバイダのレベル、準拠にかかる時間や流れ、新たに発生する費用、審査やコンサルティングの費用などを解説しており、PCI DSS準拠の要件や予算を素早く理解できる記事になっています。
PCI 3DS準拠への3ステップ
/in Knowledge-jp, 最新情報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
• Payment Card Industry Security, IT Security Management, Cloud Service Management
• 專業認證: PCI DSS QSA, CISSP, ISMS LA
PCI DSS のインシデント対応計画(IRP)
/0 Comments/in 最新情報PCI DSS 之 Incident Response Plan
PCI DSSの要件12.10では、インシデント対応計画(IRP、Incident Response Plan)について定められています。サブ要件は6項目あり、それぞれ12.10.1~12.10.7となっています。この要件では、主に「インシデント対応計画を実施すること」、かつ「システムの不備によって引き起こされるインシデントに即座に対応できるような態勢をとること」が求められています。
PCI DSSのIRPと、他の情報セキュリティマネジメントシステム(ISO 27001等)のインシデント管理に関する規定との最大の相違点は、まず、PCI DSSの要件12.10.3で、インシデントのアラートに対応するため、24時間365日対応可能な担当者を指定するよう求めていることです。第2に、要件12.10.5で侵入検知システム(IDS)および侵入防止システム(IPS)、ファイアウォールおよびファイル整合性監視(FIM)等の警告メカニズムを実装しなければならないと定めていることです。つまり、PCI DSSのIRPは、情報セキュリティマネジメントシステム(ISMS)よりも、実施面での要求が厳しいということです。
また、要件12.10.1では、IRPの実施内容に、セキュリティインシデント発生時の役割、責任、連絡方法を含めるよう求めています。これには、カードブランドへの通知体制、各ブランド(VISA、MASTER等)が要求する対応報告が含まれます。その他、データのバックアップ、ビジネスの復旧と継続等の文書化に関する要件は、ISMSと大きな違いはありません。
また、12.10.7ではカード番号(PAN)および機密認証データ(SAD)が検出された場合にアラートを発し、対応措置をとるよう定めています。なお、12.10のその他の要件では、担当者はセキュリティ脆弱性への対応責任について適切な訓練を受けること、毎年少なくとも1回はIRPの見直しと演習(またはテスト)を行うこと、過去の経験やインシデントを踏まえてインシデント対応計画(IRP)を変更および改善することなどが定められています。
セキュアベクターズ・シニアコンサルタントの林宜鴻氏は、「これまで多くのクライアントを支援してきましたが、大部分の企業は、IRPの演習に参加するのはIT部門のスタッフ(システム管理者、ネットワーク管理者、データベース管理者)だけでよく、多くても開発者とカスタマー窓口の担当者が加わる程度だと考えています。なぜなら、手順文書は普通、担当者の役割や責任、すべきこと等を大まかに説明しているだけだからです」と話します。しかし、シニアコンサルタントからカード会員データが流出した場合のシミュレーションを提示されると、手順文書の中に上司に報告すべきかどうかの基準がないこと、誰に報告するかも明確でないこと、すぐにIT部門に調査を依頼できるか、あるいは全部直接社長に報告するのかなど、クライアントは様々なことに気が付きます。そしてこれらは、いずれも演習の過程での課題になります。
したがって、セキュアベクターズのコンサルタントがIRPの演習を支援する際は、クライアント企業の業務の過程で起こりうるインシデントの状況を綿密にシミュレートし、クライアントがPDI DSSの要件通りに連絡や対応ができるよう支援する必要があります。
セキュアベクターズは、金融決済のセキュリティ分野で業界最高のコンサルティングと、PCI DSS審査サービスを提供しています。
詳細は以下の公式サイトをご覧下さい。
https://www.securevectors.com/ja/pci-dss/
#PCIDSS #PCISSC #QSA (Qualified Security Assessors) #VISA#Master #SAQ(Self-Assessment Questionnaire) #AOC (Attestation of Compliance)#ASV (Approved Scanning Vendors) #卡組織 #IDS #IPS#IRP #FIM







