PCI DSS（Payment Card Industry Data Security Standard）は、クレジットカード会員のカード情報や取引情報の安全を確保するために策定された、クレジットカード事業者およびその加盟店向けのグローバルなセキュリティ基準です。
経済産業省も、EC加盟店がクレジットカード情報を保持する条件としてPCI DSSへの準拠を求めるとする発表をしており、クレジットカード事業者やEC加盟店は対応を避けられません。
当ページでは、PCI DSSとは何か、またPCI DSSに準拠する方法を解説します。
クレジットカードに関するセキュリティ基準PCI DSS
PCI DSS（Payment Card Industry Data Security Standard）はPCI Security Standards Council により策定されたセキュリティ基準です。 PCI DSSとはどのような基準なのでしょうか。
■PCI DSS策定の経緯
American Express、 Discover Financial Services、JCB International、MasterCard、Visa Inc.の5社共同で策定したカード情報セキュリティの国際統一基準がPCI DSSです。
カード会社や加盟店、プロセサー（決済処理代行事業者）など、カード情報を管理・処理・送信するすべての組織が対象になります。
PCI DSSを策定するきっかけとなったのが、2005年に大手プロセサーから4,000万件もの情報が流出した米国での事例です。
PCI DSSの策定以前はクレジットカードブランドごとに独自のセキュリティ基準を採用していたため基準の統一が望まれていたという背景もあり、PCI DSSは米国で一気に普及しました。
■PCI DSSの管理団体PCI Security Standards Council
PCI DSS の策定にあたり、American Express、 Discover Financial Services、JCB International、MasterCard、Visa Inc. はカード会員情報の保護を目的としたPCI Security Standards Councilを設立しました。
PCI Security Standards CouncilがPCI DSSの管理を行っています。
■PCI DSSの12要件
PCI DSSでは、以下６つのデータセキュリティ基準が定められ、更に12項目の要件として定義されています。
後述の通り、PCI DSS は定期的に更新されているものの、重要な基盤となるこれら12項目のPCI DSS要件は基本的に変更されることはないとPCI Security Standards Councilは 述べています。
安全なネットワークとシステムの構築と維持
1． カード会員データを保護するために、ファイアウォールをインストールして維持する
2． システムパスワードおよびその他のセキュリティパラメータにベンダー提供のデフォルト値を使用しない
カード会員データの保護
3. 保存されるカード会員データを保護する
4. オープンな公共ネットワーク経由でカード会員データを伝達する場合、暗号化する
脆弱性管理プログラムの整備
5. すべてのシステムをマルウェアから保護し、ウイルス対策ソフトウェアまたはプログラムを定期的に更新する
6. 安全性の高いシステムとアプリケーションを開発し、保守する
強力なアクセス制御手法の導入
7. カード会員データへのアクセスを、業務上必要な範囲内に制限する
8. システムコンポーネントへのアクセスを確認・許可する
9. カード会員データへの物理アクセスを制限する
ネットワークの定期的な監視およびテスト
10. ネットワークリソースおよびカード会員データへのすべてのアクセスを追跡および監視する
11. セキュリティシステムおよび管理手順を定期的にテストする
情報セキュリティポリシーの維持
12. すべての担当者の情報セキュリティに対応するポリシーを整備する
PCI DSSでは、情報セキュリティに対する施策が具体的かつ定量的に示されていることから、米国では加盟店以外の企業でも採用が進んでいます。
PCI DSSのバージョンについて
PCI Security Standards Council はPCI DSSを定期的に更新しています。PCI DSSの歴史を追うことでクレジットカード取引にまつわる脅威状況の移り変わりも見えてきます。
■ PCI DSS 3.2.1（2018年）
2019年10月時点の最新バージョンです。 PCI DSS 3.2.1では、多要素認証に関連する要件などを含む、サービスプロバイダーの5つの新しいサブ要件を確認しています。
また、PCI DSS は 2020年を目途にバージョン4.0を発行予定であると 発表しています。主に、2017年度に実施したステークホルダーからのレビュー内容を反映する更新となる予定です。
■ PCI DSS 3.0（2015年）
DSS 3.0では、クレジットカードを受け入れる企業の全従業員のセキュリティ教育と意識の向上など、3つの主要な分野が強調されました。
■ PCI DSS 2.0（2010年）
DSS 2.0は、評価プロセスの合理化を意図して発行されています。
■ PCI DSS 1.2（2008年）
DSS 1.2では、ワイヤレスネットワークの保護とウイルス対策ソフトウェアの実装に関するガイダンスが追加されました。
■ PCI DSS 1.1（2006年）
DSS 1.1では、追加のセキュリティ対策として加盟店に対し、すべてのオンラインアプリケーションのレビューとファイアウォールの設置を要求しています。
■ PCI DSS 1.0（2004年）
DSSの初版。PCIの設立メンバーであるAmerican Express、Discover Financial Services、JCB International、Mastercard、Visaが2004年、PCI DSS 1.0を導入しました。
また、これら５社のブランドを採用する加盟店はすべて、PCI DSSへの準拠が求められました。
EC加盟店はPCI DSSへの準拠必須
気軽にクレジットカード決済ができることになったことで買い物の利便性が増す一方、ECサイトのアプリケーションの脆弱性をついたサイバー攻撃や、セキュリティレベルの低い公衆無線LANを悪用したなりすまし犯行により、情報漏えいやクレジットカードの不正利用が多発するようになりました。
このような背景を受け、2017年、経済産業省は「 クレジットカード取引におけるセキュリティ対策の強化に向けた実行計画2017」を新たに策定しました。
■PCI DSSの遵守が必要な事業者
経済産業省の実行計画の中で、PCI DSSへの準拠完了の目標スケジュールが示されています
2018 年 3 月末までに、特にカード情報の漏えいの頻度が高い非対面（EC）加盟店については原則として非保持化（保持する場合はPCI DSS 準拠）を推進するとともに、カード会社（イシュアー・アクワイアラー）及び PSP については PCI DSS 準拠を求めることとする。
また、改正割賦販売法が遅くとも 2018 年 6 月に施行されることから、対面加盟店においても、その時までの対応を基本とし、最終的には、全加盟店が 2020 年 3 月末までにカード情報の適切な保護に関する対応（非保持化又は PCI DSS 準拠）が完了している状態になっていることを目指す。
すなわち次のとおり、クレジットカード情報を保持する事業者にとっては、PCI DSSへ準拠しないという選択肢はありません。
- EC加盟店（非対面加盟店）は、2018年3月末までにクレジットカード情報の非保持化（カード情報を保持する場合はPCI DSS準拠）
- カード会社およびPSPは、2018年3月末までにPCI DSSへの準拠
- 対面加盟店は、2018 年 6 月までにクレジットカード情報の非保持化または PCI DSS 準拠
- 最終的には全加盟店が、 2020 年 3 月末までにクレジットカード情報の非保持化または PCI DSS 準拠
また、各事業者はカード情報の非保持化に対応した場合であっても、情報の保護に関する従業員教育やマルウェア対策は継続し、必要なセキュリティ対策を講じてデバイス管理することが要求されています。
■PCI DSS準拠から得られるメリット
クレジットカード事業者や加盟店以外の事業者でもPCI DSS へ準拠することにより次のようなメリットがあります。
- 企業の信用やブランドの向上につながり企業価値が高まる。
- 具体的なセキュリティポリシーが定義されるため、自社のサイトを不正アクセスから保護できる。
- サイトの改ざんや悪用、情報収集のリスクが低減する。
PCI DSSは国際カードブランド5社が策定していることから、特に企業価値の向上のメリットが大きいと言えそうです。
PCI DSS認証を取得するには
PCI DSS認証を取得する方法や認定審査機関について説明します。
■PCI DSS認証方法
PCI DSSの認証を得るには次のような方法があります。
訪問審査 | 認定審査機関（Qualified Security Assessor , QSA）による訪問審査を受けて認証を取得する方法。 カード発行会社など規模の大きな事業者に対して要請されている方法です。 |
|---|---|
ネットワークスキャン（外部ネットワークシステムの脆弱性スキャン） | WEBサイトからの侵入により情報が収集されてしまうことがないか、ベンダー(Approved Scanning Vendor, ASV) のスキャンツールによる点検を受けて、サイトに脆弱性のない旨の認証を得ます。 中規模事業者やインターネットに接続している事業者には必須の方法です。 |
自己問診 | PCI DSSの要求事項に基づいたチェック項目に回答して、すべて「Yes」であれば、準拠と認められます。一般加盟店などの小規模事業者向けの方法です。 |
これら3種類の認証方法については、カード情報の取り扱い規模や事業形態によって異なります。
■認定審査機関
訪問審査を行い、PCI DSS準拠の状況を確認および判定するのが認定審査機関（Qualified Security Assessor , QSA）です。
QSAの一覧は、PCI Security Standards Councilの Webサイトで確認でき、2019年10月現在では日本国内で32社ほどのQSAが訪問審査を行っています。
PCI DSS対応の進め方
企業がPCI DSSへ準拠し、認証を取得するときはどのようなフローで準備を進めれば良いでしょうか。
■PCI DSS対応のプロセス
PCI DSSの認証取得に向け、企業で実施すべき一般的な手順は次のとおりです。
PCI DSS準拠の対象範囲を確定
カード会員情報の取り扱い範囲を特定し、自社のサービスやシステムを踏まえて、PCI DSSに準拠すべき範囲を確定します。
改善計画の立案
現状のセキュリティ対策状況とPCI DSSでの要求事項とのギャップを分析します。分析結果基づいて改善計画書を策定します。
対策の実行
計画に沿って対策を実行します。運用手順書やポリシーの文書化も含みます。必要に応じてシステムの再設計やセキュリティソフトウェアなどの実装も行います。
テストの実施と本審査
システムスキャンやセキュリティチェックテストを実施します。テスト結果に基づきシステム改修などの対応をします。また、審査機関（QSA）によるPCI DSS認定審査に向けた準備や調整も行います。
■PCI DSS Ver3.2.1の要約版（PCI DSS準拠に向けてのヒント）を公開
ゾーホージャパン株式会社には、「PCI DSS準拠の重要性は理解したが、原文が分かりにくい。」という声が多く寄せられました。 そこで、ゾーホージャパンはPCI DSS Ver3.2.1のポイントをまとめた要約版「PCI DSS準拠に向けてのヒント」を作成し、無償提供する運びとなりました。 「PCI DSS 準拠に向けてのヒント」は、以下よりダウンロードできます。
■PCI DSS要件に対するレポート生成や関連機能を提供する「ManageEngine」
このように流れはシンプルに見えますが、特に改善計画を作成するにあたりPCI DSS要件を読み解いて分析するというステップには、かなりの工数と知見とを要することが分かります。
ManageEngineでは、PCI DSS要件に対するコンプライアンスレポートの生成や関連機能の提供に対応しています。
次表は、PCI DSSの各要件と対応するManageEngineの製品・機能をまとめたものです。
| ManageEngineのPCI DSS準拠ソリューション | ||||||||
|---|---|---|---|---|---|---|---|---|
PCI DSSでは、以下のデータセキュリティ基準が定められ、それぞれ6つの目標と12項目の要件を定義しています。 PCI DSSの準拠要件に対応するManageEngine製品のソリューション一覧については、 | ||||||||
| 目標 | 要件 | 要件に対応するME製品 | ||||||
| 安全なネットワークとシステムの構築と維持 |
| |||||||
| カード会員データの保護 |
| |||||||
| 脆弱性管理プログラムの整備 |
| |||||||
| 強力なアクセス制御手法の導入 |
| |||||||
| ネットワークの定期的な監視およびテスト |
| |||||||
| ネットワークの定期的な監視およびテスト | 12.すべての担当者の情報セキュリティに対応するポリシーを整備する | Endpoint Central Password Manager Pro | ||||||
| 付録A 1 | ||||||||
※ 本資料は、Password Manager Pro/EventLog Analyzer、その他関連製品のレポート出力項目および関連機能を列挙したものであり、PCI DSSを用いた監査/認定審査等への適合性を保証するものではありません。
■PCI DSS準拠のソリューションを実現するManageEngine製品
上述のPCI DSS準拠のソリューションを実現するManageEngine製品は次のとおりです。（製品名をクリックすると、各製品紹介ページを参照できます。）
簡易SIEMソフト「Log360」
特権ID管理システム「Password Manager Pro」
ファイアウォールログ解析ソフト「Firewall Analyzer」
ネットワーク機器コンフィグ管理ソフト「Network Configuration Manager」
サービスデスクツール「ServiceDesk Plus」
統合エンドポイント管理（UEM）ソフト「Endpoint Central」
|
|
| |
| 要件1:カード会員データを保護するために、ファイアウォールをインストールして構成を維持する | |||
| 1.1.1すべてのネットワーク接続およびファイアウォール/ルーター構成への変更を承認およびテストする正式なプロセス | <コンプライアンス機能>FWのコンフィグ情報を定期的に取得し過去の変更確認が可能 | <コンフィグ確認機能>コンフィグレビューの実施が可能(画面上で参照)コンフィグアップロードについて許可を要求する権限と承認する権限に分けて、承認フローが可能 | |
| 1.1.7ファイアウォールおよびルーターのルールセットは少なくとも6カ月ごとにレビューされる必要がある | <コンプライアンス機能>未使用ルールレポートを確認することで、不要なルール、オブジェクトの洗い出しが可能 | <変更履歴>コンフィグおよび変更履歴を目視で確認可能 | |
| 1.2信頼できないネットワークとカード会員データ環境内のすべてのシステムコンポーネントの接続を制限する、ファイアウォールとルーターの構成を構築する。 注:「信頼できないネットワーク」とは、レビュー対象の事業体に属するネットワーク外のネットワーク、または事業体の制御または管理が及ばないネットワーク（あるいはその両方）のことである。 | |||
| 1.2.1着信および発信トラフィックを、カード会員データ環境に必要なトラフィックにし、それ以外のすべてのトラフィックを特定的に拒否する。 | |||
| 1.2.2ルーター構成ファイルをセキュリティ保護および同期化する。 | <コンフィグ(runningとstartup)の同期機能>同期していないコンフィグをリストアップし、同期処理が可能 ※本製品でサポートしている機器が対象 | ||
| 1.2.3すべてのワイヤレスネットワークとカード会員データ環境の間に境界ファイアウォールをインストールし、ワイヤレス環境とカード会員データ環境間のトラフィックを拒否または、業務上必要な場合、承認されたトラフィックのみを許可するようにファイアウォールを構成する。 | |||
| 1.3インターネットとカード会員データ環境内のすべてのシステムコンポーネント間の、直接的なパブリックアクセスを禁止する。 | |||
| 1.3.1 DMZを実装し、承認された公開サービス、プロトコル、ポートを提供するシステムコンポーネントのみへの着信トラフィックに制限する。 | |||
| 1.3.2着信インターネットトラフィックをDMZ内のIPアドレスに制限する。 | |||
| 1.3.3アンチスプーフィング対策を実施し、偽の送信元IPアドレスを検出して、ネットワークに侵入されないようにブロックする。 （たとえば、内部送信元アドレスを持つインターネットからのトラフィックをブロックするなど。） | |||
| 1.3.4カード会員データ環境からインターネットへの不正な発信トラフィックを禁止する。 | |||
| 1.3.5ネットワーク内へは、「確立された」接続のみ許可する。 | |||
| 1.3.6 DMZやその他の信頼できないネットワークから隔離されている内部ネットワークゾーンで、カード会員データを保存するコンポーネント（データベース）が実装されている。 | |||
| 1.3.7プライベートIPアドレスとルーティング情報を許可されていない第三者に開示しない。 注: IPアドレスを開示しない方法には、以下のものが含まれるが、これらに限定されるわけではない:
| |||
1.4インターネットに直接接続するポータブルコンピュータデバイス（会社あるいは従業員が所有するものも含む）で、ネットワークの外側ではインターネットに接続され、またCDEへのアクセスにも使用されるものに（従業員が使用するラップトップなど）、パーソナルファイアウォールソフトウェアか同等機能のソフトウェアをインストールする。ファイアウォール（またはそれに相当する）構成には以下が含まれます。
| <デバイス管理機能> ファイアウォールや.exe、.msi形式のアプリケーションをクライアントにインストールでき、アプリケーションの管理と監視が可能 モバイル機器については、ファイアウォール アプリケーションのインストールや、インベントリコンソールからアプリケーションステータスの監視が可能 | ||
| 1.5ファイアウォールの管理に関するセキュリティポリシーと操作手順が文書化および使用されており、影響を受ける関係者全員に知らされていることを確認する。 |
|
| |
| 要件2:システムパスワードおよび他のセキュリティパラメータにベンダ提供のデフォルト値を使用しない | ||
| 2.1システムをネットワークに導入する前に、必ずベンダ提供のデフォルト値を変更し、不要なデフォルトアカウントを無効にする。 これは、オペレーティングシステム、セキュリティサービスを提供するソフトウェア、アプリケーション、システムアカウント、POS端末、ペイメントアプリケーション、簡易ネットワーク管理プロトコル（SNMP）コミュニティ文字列で使用されるがこれらに限定されない、すべてのデフォルトパスワードに適用されます。 | <ユーザー管理機能>強固なパスワード生成による、デバイスへのハッキング防止が可能 | <アカウントディスカバリー機能>各サーバーローカルに登録しているアカウントをリストアップ可能<レポート機能>製品内で指定したポリシーに違反するパスワードを持つアカウントをリストアップ可能 |
| 2.1.1カード会員データ環境に接続されている、またはカード会員データを伝送するワイヤレス環境の場合、インストール時にすべてのワイヤレスベンダのデフォルト値を変更する。これには、デフォルトのワイヤレス暗号化キー、パスワード、SNMPコミュニティ文字列が含まれるが、これらに限定されない。 | ||
| 2.2すべてのシステムコンポーネントについて、構成基準を作成する。この基準は、すべての既知のセキュリティ脆弱性をカバーし、また業界で認知されたシステム強化基準と一致している必要がある。 業界で認知されたシステム強化基準のソースには以下が含まれる（これらに限定されない）。
| ||
| 2.2.1同じサーバに異なったセキュリティレベルを必要とする機能が共存しないように、1つのサーバには、主要機能を1つだけ実装する。（たとえば、Webサーバ、データベースサーバ、DNSは別々のサーバに実装する必要がある。） 注:仮想化テクノロジを使用している場合は、1つの仮想システムコンポーネントに主要機能を1つだけ実装する。 | ||
| 2.2.2システムの機能に必要なサービス、プロトコル、デーモンなどのみを有効にする。 | ||
| 2.2.3安全でないとみなされている必要なサービス、プロトコル、またはデーモンに追加のセキュリティ機能を実装する。 注: SSL/early TLSが使用されている場合、付録A2の要件が満たされている必要がある。 | ||
| 2.2.4システムセキュリティのパラメータが、誤用を防ぐために設定されている。 | ||
| 2.2.5スクリプト、ドライバ、機能、サブシステム、ファイルシステム、および不要なWebサーバなど、すべての不要な機能を削除する。 | ||
| 2.3強力な暗号化を使用して、すべてのコンソール以外の管理アクセスを暗号化する。 注: SSL/early TLSが使用されている場合、付録A2の要件が満たされている必要がある。 | <踏み台機能>接続するプロトコルをSSHのみに制限することで対応が可能 | |
| 2.4 PCI DSSの適用範囲であるシステムコンポーネントのインベントリを維持する。 | <インベントリ管理機能> 定期的にデスクトップ/サーバー/モバイル機器をスキャンし、ソフトウェアやハードウェアの情報収集が可能 また、レポートにより内容の確認が可能 | |
| 2.5ベンダデフォルト値およびその他のセキュリティパラメータの管理に関するセキュリティポリシーと操作手順が文書化されて使用されており、影響を受ける関係者全員に知られていることを確認する。 | ||
| 2.6共有ホスティングプロバイダは、各事業体のホスト環境およびカード会員データを保護する必要がある。これらのプロバイダは、付録A1:「共有ホスティングプロバイダでの追加PCI DSS要件」に示されているように、特定の要件を満たす必要がある。 |
| |
| 要件3:保存されるカード会員データを保護する | |
3.1データ保存および廃棄ポリシー、手順、プロセスを実装し、すべてのカード会員データ（CHD）ストレージに少なくとも以下のものを含めようにすることで保存するカード会員データを最小限に抑える。
| |
| 3.2承認後に機密認証データを保存しない（暗号化されている場合でも）。機密認証データを受け取った場合、認証プロセスが完了し次第すべてのデータを復元不可能にする。 以下の場合に、データが安全に保存される場合は、発行者と企業が、機密認証データを保存するため、発行サービスをサポートすることが可能である。
機密認証データには、以降の要件3.2.1～3.2.3で言及されているデータを含む。 | |
| 3.2.1（カードの背面やチップ上の同等のデータなどにある磁気ストライプの）追跡データの完全な内容を承認後に保存しない。このデータは、全トラック、トラック、トラック1、トラック2、磁気ストライプデータとも呼ばれます。 注:通常の取引過程では、磁気ストライプからの以下のデータ要素を保存する必要が生じる場合があります。
リスクを最小限に抑えるため、取引に必要なデータ要素のみを保存します。 | |
| 3.2.2カードを提示しない取引を検証するために使用された、カード検証コードまたは値（ペイメントカードの前面または背面に印字されている3桁または4桁の数字）を承認後に保存しない。 | |
| 3.2.3個人識別番号（PIN）または暗号化されたPINブロックを承認後に保存しない。 | |
3.3表示時にPANをマスクして（最初の6桁と最後の4桁が最大表示桁数）、業務上の正当な必要性がある関係者だけがPANの最初の6桁と最後の4桁以外の桁を見ることができるようにする。 注:カード会員データの表示（法律上、またはペイメントカードブランドによるPOSレシート要件など）に関するこれより厳しい要件がある場合は、その要件より優先されることはありません。 | |
3.4以下の手法を使用して、すべての保存場所でPANを少なくとも読み取り不能にする（ポータブルデジタルメディア、バックアップメディア、ログを含む）。
注:悪意のある個人がトランケーションされたPANとハッシュ化されたPANの両方を取得した場合、元のPANを比較的容易に再現することができます。ハッシュ化および切り捨てられたPANの同じバージョンが事業体の環境に存在する場合、元のPANを再構築するために、ハッシュ化および切り捨てられたバージョンを関連付けることはできないことを確認する追加コントロールを導入する必要があります。 | |
3.4.1（ファイルまたは列レベルのデータベース暗号化ではなく）ディスク暗号化が使用される場合、論理アクセスはネイティブなオペレーティングシステムの認証およびアクセス制御メカニズムとは別に管理する必要がある（ローカルユーザアカウントデータベースや一般的なネットワークログイン資格情報を使用しないなどの方法で）。復号キーがユーザアカウントと関連付けられていない。 注:この要件は他のすべてのPCI DSS暗号化およびキー管理要件に加えて適用されます。 | |
3.5.1サービスプロバイダ用の追加要件:以下を含む暗号化アーキテクチャの説明文書を整備する:
注:この要件は、2018年1月31日まではベストプラクティスとみなされ、それ以降は要件になる。 | <共有、アクセス制御機能> 暗号化キーへのアクセスが可能なユーザーを制御可能 |
| 3.5.2暗号化キーへのアクセスを、必要最小限の管理者に制限する。 | <共有機能> 共有設定により利用ユーザーの制限が可能 また、暗号化キーは取得できないように制御も可能 |
3.5.3カード会員データの暗号化/復号に使用される秘密キーは、以下のいずれかの形式（複数可）で常時保存する。
注:公開キーがこれらの形式で保存されていることは要求されていません。 | |
| 3.5.4暗号化キーを最小限の場所に保存する。 | |
3.6カード会員データの暗号化に使用される暗号化キーの管理プロセスおよび手順をすべて文書化し、実装する。これには、以下が含まれる。 注:キー管理には多数の業界標準があり、NIST（http://csrc.nist.govを参照）などさまざまなリソースから入手可能です。 | |
| 3.6.1強力な暗号化キーの生成 | |
| 3.6.2安全な暗号化キーの配布 | |
| 3.6.3安全な暗号化キーの保存 | |
| 3.6.4関連アプリケーションベンダまたはキーオーナーが定義し、業界のベストプラクティスおよびガイドライン（たとえば、NIST SP 800-57）に基づいた、暗号化期間の終了時点に到達したキーの暗号化キーの変更。暗号化期間の終了時点とは、たとえば、定義された期間が経過した後、または付与されたキーで一定量の暗号化テキストを作成した後（またはその両方）である。 | |
3.6.5クリアテキストキーの知識を持つ従業員が離職したなど、キーの整合性が脆弱になっている場合、またはキーの脆弱性が悪用された可能性がある場合に必要な、キーの破棄または取り替え（アーカイブ、破壊、無効化など）。 注:破棄された、または取り替えられた暗号化キーを保持する必要がある場合、そのキーを（たとえば、キー暗号化キーを使用することにより）安全にアーカイブする必要がある。アーカイブされた暗号化キーは、復号/検証の目的のためにのみ使用できます。 | |
3.6.6平文暗号化キー管理を手動で操作する場合、キーの知識分割と二重管理を使用する必要がある。 注:手動のキー管理操作の例には、キーの生成、伝送、読み込み、保存、破棄などが含まれますが、これらに限定されません。 | |
| 3.6.7暗号化キーの不正置換の防止。 | |
| 3.6.8暗号化キー管理者が自身の責務を理解し、キー管理者としての責務を受諾する。 | |
| 3.7保存されているカード会員データを保護するためのセキュリティポリシーと操作手順が文書化および使用されており、影響を受ける関係者全員に知られていることを確認する。 |
| 要件4:オープンな公共ネットワーク経由でカード会員データを伝送する場合、暗号化する |
4.1オープンな公共ネットワーク経由で機密性の高いカード会員データを伝送する場合、以下を含む強力な暗号化とセキュリティプロトコルを使用する。
注: SSL/early TLSが使用されている場合、付録A2の要件が満たされている必要がある。 オープンな公共ネットワークの例として以下が挙げられるが、これらに限定されない。
|
| 4.1.1カード会員データを伝送する、またはカード会員データ環境に接続されているワイヤレスネットワークが、認証および伝送用に強力な暗号化を実装するため、業界のベストプラクティスを使用していることを確認する。 |
| 4.2保護されていないPANをエンドユーザメッセージングテクノロジ（電子メール、インスタントメッセージング、SMS、チャットなど）で送信しない。 |
| 4.3カード会員データの伝送を暗号化するためのセキュリティポリシーと操作手順が文書化されて使用されており、影響を受ける関係者全員に知られていることを確認する。 |
| |
| 要件5:ウィルス対策ソフトウェアまたはプログラムを使用し、定期的に更新する | |
| 5.1悪意のあるソフトウェアの影響を受けやすいすべてのシステム（特にパーソナルコンピュータとサーバ）に、ウィルス対策ソフトウェアを導入する。 | <ソフトウェアインストール機能> システムごとにカスタムグループを作成し、特定のグループ単位でアンチウイルスソフトの設定が可能 |
| 5.1.1ウィルス対策プログラムが、既知の悪意のあるソフトウェアの全タイプに対して、検出、削除、保護が可能であることを確認する。 | |
| 5.1.2一般的に悪意のあるソフトウェアに影響されないとみなされているシステムでは、定期的に評価を行って、進化を続けるマルウェアの脅威を特定して評価することで、システムにウィルス対策ソフトウェアが依然として必要ないかどうかを判断する。 | <パッチ管理機能> 定期的なパッチ更新やリリースされたパッチを自動的に配布可能 また、ウイルス、トロイの木馬、ワームなどのマルウェア・スパイウェアなどに対するアンチウイルス定義の自動更新も可能 |
5.2すべてのウィルス対策メカニズムが以下のように維持されていることを確認する。
| <パッチ管理機能>定期的なパッチ更新やリリースされたパッチを自動的に配布可能 また、ウイルス、トロイの木馬、ワームなどのマルウェア・スパイウェアなどに対するアンチウイルス定義の自動更新も可能 古いアンチウイルスソフトウェアやパッチを探知し、更新することが可能 また、MS Forefont Client Securityの定義ファイル更新も可能 |
5.3ウィルス対策メカニズムがアクティブに実行されており、経営管理者からケースバイケースで期間を限って特別に許可されない限り、ユーザが無効にしたり変更できないことを確認する。 注:ウィルス対策ソリューションは、ケースバイケースで経営管理者により許可されたことを前提に、正当な技術上のニーズがある場合に限り、一時的に無効にすることができます。特定の目的でアンチウィルス保護を無効にする必要がある場合、正式な許可を得る必要があります。アンチウィルス保護が無効になっている間、追加のセキュリティ手段が必要になる場合があります。 | |
| 5.4マルウェアからシステムを保護するためのセキュリティポリシーと操作手順が文書化されて使用されており、影響を受ける関係者全員に知られていることを確認する。 |
|
| |
| 要件6:安全性の高いシステムとアプリケーションを開発し、保守する | ||
6.1セキュリティ脆弱性情報の信頼できる社外提供元を使ってセキュリティの脆弱性を特定し、新たに発見されたセキュリティの脆弱性にリスクのランク（「高」、「中」、「低」など）を割り当てるプロセスを確立する。 注:リスクのランク分けは、業界のベストプラクティスと考えられる影響の程度に基づいている必要があります。たとえば、脆弱性をランク分けする基準は、CVSSベーススコア、ベンダによる分類、影響を受けるシステムの種類などを含む場合があります。 脆弱性を評価し、リスクのランクを割り当てる方法は、組織の環境とリスク評価戦略によって異なります。リスクのランクは、最小限、環境に対する「高リスク」とみなされるすべての脆弱性を特定するものである必要があります。リスクのランク分けに加えて、環境に対する差し迫った脅威をもたらす、重要システムに影響を及ぼす、対処しないと侵害される危険がある場合、脆弱性は「重大」とみなされます。重要システムの例としては、セキュリティシステム、一般公開のデバイスやシステム、データベース、およびカード会員データを保存、処理、送信するシステムなどがあります。 | <パッチ管理機能>定期的なパッチ更新やリリースされたパッチを自動的に配布可能 また、ウイルス、トロイの木馬、ワームなどのマルウェア・スパイウェアなどに対するアンチウイルス定義の自動更新も可能 組織内のネットワークにおけるシステムを定期的にスキャンし、欠如しているパッチを検出可能 また、脆弱性のランク（カスタム可能）に基づき欠如しているパッチを配布することで、システムに最新のパッチが適用された状態を保つことが可能 | |
| 6.2すべてのシステムコンポーネントとソフトウェアに、ベンダ提供のセキュリティパッチがインストールされ、既知の脆弱性から保護されている。重要なセキュリティパッチは、リリース後1カ月以内にインストールする。 注:要件6.1で定義されているリスクのランク分けプロセスに従って、重要なセキュリティパッチを識別する必要があります。 | <パッチ管理機能> Microsoftの提供するパッチや、システムの脆弱性に基づくパッチ配布が可能 また、自動パッチ管理機能を使用することで、定期的なパッチ更新やリリースされたパッチの自動配布が可能 パッチ適用状況はEndpoint Centralに随時アップデートされ、レポートとして確認が可能 | |
6.3内部および外部ソフトウェアアプリケーション（アプリケーションへのWebベースの管理アクセスを含む）を次のように開発する。
注:これは、社内開発ソフトウェアすべて、および第三者によって開発されたカスタムソフトウェアにも当てはまります。 | ||
| 6.3.1アプリケーションがアクティブになる前、または顧客にリリースされる前に、テスト/カスタムアプリケーションアカウント、ユーザID、パスワードを削除する。 | ||
6.3.2コーディングの脆弱性がないことを確認するための、本番または顧客のリリース前のカスタムコードを、少なくとも以下の各項を含めてレビューする（手動または自動プロセスによる）。
注:このコードレビュー要件は、システム開発ライフサイクルの一環として、すべてのカスタムコード（内部および公開）に適用される。コードレビューは、知識を持つ社内担当者または第三者が実施できます。一般に公開されているWebアプリケーションは、実装後の脅威および脆弱性に対処するために、PCI DSS要件6.6に定義されている追加コントロールの対象となる。 | ||
| 6.4システムコンポーネントへのすべての変更において、変更管理のプロセスおよび手順に従う。これらのプロセスには、以下を含める必要がある。 | ＜変更管理機能＞ 変更管理のプロセスの実装が可能 | |
| 6.4.1開発/テスト環境を本番環境から分離し、分離を実施するためのアクセス制御を行う。 | ||
| 6.4.2開発/テスト環境と本番環境での責務の分離 | ||
| 6.4.3テストまたは開発に本番環境データ（実際のPAN）を使用しない | ||
| 6.4.4システムがアクティブ/実稼働になる前に、システムコンポーネントからテストデータとテストアカウントを削除する。 | ||
| 6.4.5変更管理手順には、以下を含める必要がある。 | ||
| 6.4.5.1影響の文書化。 | ＜変更管理機能＞ 影響範囲について文書化して、SDPの変更管理チケット関連付けが可能 | |
| 6.4.5.2適切な権限を持つ関係者による文書化された変更承認。 | ＜変更承認機能＞ 変更承認機能を利用して承認履歴の記録が可能 | |
| 6.4.5.3変更がシステムのセキュリティに悪影響を与えないことを確認するための機能テスト。 | ＜変更計画の提出＞ ＜変更の実装＞ | |
| 6.4.5.4回復手順。 | ＜変更承認機能＞ 問題発生時の回復手順について文書化し、変更承認の中でレビュー可能 | |
6.4.6大幅な変更の完了時に、ただちにすべての関連PCI DSS要件を新規または変更されたシステムとネットワークに適用し、ドキュメントを適宜更新する必要がある。 注:この要件は、2018年1月31日まではベストプラクティスとみなされ、それ以降は要件になる。 | ||
6.5次のようにしてソフトウェア開発プロセスで一般的なコーディングの脆弱性に対応する。
注:要件6.5.1～6.5.10に挙げられている脆弱性は、このバージョンのPCI DSSが発行された時点の最新の業界ベストプラクティスを踏襲しているが、脆弱性管理のための業界のベストプラクティスは更新されているため（OWASPガイド、SANS CWE Top 25、CERT Secure Codingなど）、現在のベストプラクティスは、これらの要件を使用する必要がある。 | ||
| 注:以下の要件6.5.1から6.5.6は、すべてのアプリケーション（内部または外部）に適用されます。 | ||
| 6.5.1インジェクションの不具合（特にSQLインジェクション）。OSコマンドインジェクション、LDAPおよびXpathのインジェクションの不具合、その他のインジェクションの不具合も考慮する。 | ||
| 6.5.2バッファオーバーフロー | ||
| 6.5.3安全でない暗号化保存 | ||
| 6.5.4安全でない通信 | ||
| 6.5.5不適切なエラー処理 | ||
| 6.5.6脆弱性特定プロセス（PCI DSS要件6.1で定義）で特定された、すべての「高リスク」脆弱性。 | ||
| 注:以下の要件6.5.7〜6.5.10は、Webアプリケーションとアプリケーションインタフェースに適用されます。(内部または外部): | ||
| 6.5.7クロスサイトスクリプティング（XSS） | ||
| 6.5.8不適切なアクセス制御（安全でないオブジェクトの直接参照、URLアクセス制限の失敗、ディレクトリトラバーサル、機能へのユーザアクセス制限の失敗など） | ||
| 6.5.9クロスサイトリクエスト偽造（CSRF） | ||
| 6.5.10不完全な認証管理とセッション管理 | ||
6.6一般公開されているWebアプリケーションで、継続的に新たな脅威や脆弱性に対処し、これらのアプリケーションが、次のいずれかの方法によって、既知の攻撃から保護されていることを確認する。
| ||
| 6.7セキュアシステムとアプリケーションを開発・保守するためのセキュリティポリシーと操作手順が文書化されて使用されており、影響を受ける関係者全員に知られていることを確認する。 |
|
| |
| 要件7:カード会員データへのアクセスを、業務上必要な範囲内に制限する | ||
| 7.1システムコンポーネントとカード会員データへのアクセスを、業務上必要な人に限定する。 | <共有機能> 共有設定により利用ユーザーの制限が可能 | |
7.1.1以下を含む、各役割のアクセスニーズを定義する
| <権限設定機能>役割ベースのアクセスコントロール機能により、IT技術者は適切な権限を持つユーザーに対して、ルーティーン化している活動を委任することが可能 ※役割の作成に制限はなく、IT管理者は、Endpoint Centralユーザーに対してポリシーに基づいた委任を行うことが可能 | <承認機能、共有設定>利用者の制限が可能 |
| 7.1.2特権ユーザIDに与えるアクセス権を職務の実行に必要な最小限の特権に制限する。 | <承認機能、共有設定>利用者の制限が可能 設定内容は各種レポートで参照が可能 | |
| 7.1.3個人の職種と職務に基づくアクセス権の割り当て。 | <共有機能>共有設定により利用ユーザーの制限が可能 | |
| 7.1.4適切な権限を持つ関係者による文書化された変更承認の必要性。 | ||
7.2システムコンポーネントで、ユーザの必要性に基づいてアクセスが制限され、特に許可のない場合は「すべてを拒否」に設定された、アクセス制御システムを確立する。 アクセス制御システムには以下の項目を含める必要がある。 | <共有機能>共有されたアカウント以外の参照は不可となり、必要最低限のみの共有が可能 | |
| 7.2.1すべてのシステムコンポーネントを対象に含む | ||
| 7.2.2職種と職務に基づく、個人への特権の付与。 | <共有機能>各個人へ必要なリソース、アカウントの共有が可能 | |
| 7.2.3デフォルトでは「すべてを拒否」の設定。 | ||
| 7.3カード会員データへのアクセスを制限するためのセキュリティポリシーと操作手順が文書化されて使用されており、影響を受ける関係者全員に知られていることを確認する。 |
|
| |
| 要件8:コンピュータにアクセスできる各ユーザに一意のIDを割り当てる | ||
| 8.1ポリシーと手順を定義して実装することで、次のように、すべてのシステムコンポーネントで、非消費者ユーザと管理者のための適切なユーザ識別および認証の管理が行われるようにする。 | <共有機能> すべてのユーザーが一意なユーザー名を持つように設定することで、ユーザーの識別や管理が可能 | |
| 8.1.1システムコンポーネントまたはカード会員データへのアクセスを許可する前に、すべてのユーザに一意のIDを割り当てる。 | ||
| 8.1.2追加、削除、ユーザIDの変更、資格情報、およびその他の識別オブジェクトを管理する。 | <主機能> PMP管理者より特権ID管理が可能 | |
| 8.1.3契約終了したユーザのアクセスを直ちに取り消す。 | <ユーザー機能>ユーザーの権限を無効化することで、システム利用の制限が可能 ログイン中は、強制ログアウトが行えないためPMPの再起動により対応が可能 | |
| 8.1.4 90日以内に非アクティブなユーザアカウントを削除/無効にする。 | <ユーザー管理・レポート機能>システムの停止時間が、定義した時間を経過した場合、IT管理者に対して通知を行うことが可能 また、任意の期間内における非アクティブユーザーの一覧を、レポート画面から表示可能 | <レポート機能>過去90日間、非アクティブなユーザのリストアップが可能 |
8.1.5第三者がリモートアクセス経由でシステムコンポーネントのアクセス、サポート、メンテナンスに使用するIDを以下のように管理する。
| ||
| 8.1.6 6回以下の試行で、ユーザIDをロックアウトすることによって、アクセスの試行回数を制限する。 | <ユーザー管理機能>モバイル管理により、パスワード試行回数を制約することができ、定義した値を上回って失敗した場合、自動でのアクセス拒否設定が可能 | |
| 8.1.7最低30分間、または管理者がユーザIDを有効にするまでのロックアウト期間を設定する。 | <ユーザー管理機能>モバイル管理により、アイドル状態の回数が定義した値を上回った場合は、自動的にロックする設定が可能 | |
| 8.1.8セッションのアイドル状態が15分を超えた場合、ターミナルまたはセッションを再度アクティブにするため、ユーザの再認証が必要となる。 | <セッション管理機能>管理対象クライアントがスタンバイモード後に再度認証情報の入力を要求するように設定が可能 また、リモートセッションによる接続時における、最大アイドルセッション時間を設定することができ、セッションが指定した時間を超過した場合は、リモートマシンを自動的にロックする設定が可能 | |
8.2一意のIDを割り当てることに加え、すべてのユーザを認証するため、次の方法の少なくとも1つを使用することで、すべてのシステムコンポーネント上での顧客以外のユーザと管理者の適切なユーザ認証管理を確認する。
| <ログイン機能>ログインには二要素認証を用いることで実現可能 | |
| 8.2.1すべてのシステムコンポーネントで強力な暗号化を使用して、送信と保存中に認証情報（パスワード/パスフレーズなど）をすべて読み取り不能としている。 | ||
| 8.2.2パスワードのリセット、新しいトークンの準備、新しいキーの生成など、認証情報を変更する前に、ユーザの身元を確認する。 | ||
8.2.3パスワード/パスフレーズは以下を満たす必要がある。
あるいは、上記のパラメータに等しい複雑さと強度を持つパスワード/パスフレーズ | <パスワード設定機能> モバイル管理により、IT管理者でパスワードポリシーに基づく、数字、アルファベット、パスワードの長さなどの条件定義が可能 | <パスワードポリシー機能> 複雑・高い強度のパスワードを設定可能 |
| 8.2.4ユーザパスワード/パスフレーズは、少なくとも90日ごと変更する。 | <パスワード設定機能>モバイル管理により、パスワードの有効期限設定が可能 | |
| 8.2.5これまでに使用した最後の4つのパスワード/パスフレーズのいずれかと同じである新しいパスワード/パスフレーズを許可しない。 | <パスワード設定機能>パスワード履歴の保存が可能であり、過去に設定したパスワードの再利用を禁止することが可能 | <パスワードポリシー機能>パスワードを変更する際に、過去4回分のパスワードを使用しないように設定可能 |
| 8.2.6初期パスワード/パスフレーズとリセットパスワード/パスフレーズをユーザごとに一意の値にリセットし、初回の使用後直ちに変更する。 | <パスワードポリシー機能> PMP初回利用時に、利用者へ一意のパスワードを設定するように促すことが可能 | |
8.3すべてのコンソール以外の管理アクセスとCDEに対するすべてのリモートアクセスを多要素認証を使用してセキュリティで保護する。 注:多要素認証では、3つの認証方法のうち最低2つを認証に使用する必要がある（認証方法については、要件8.2を参照）。1つの因子を2回使用すること（たとえば、2つの個別パスワードを使用する）は、多要素認証とは見なされない。 | ||
8.3.1管理アクセス権限を持つ担当者のすべてのコンソール以外のCDEへの管理アクセスに多要素認証を組み込む。 注:この要件は、2018年1月31日まではベストプラクティスとみなされ、それ以降は要件になる。 | ||
| 8.3.2ネットワーク外部からのネットワークへのリモートアクセスすべてに（ユーザと管理者、サポートやメンテナンス用の第三者のアクセスを含む）多要素認証を組み込む。 | ||
8.4以下を含む認証手順およびポリシーを文書化し、すべてのユーザに通達する。
| <踏み台機能>接続方法を制限した機器へログオンが可能 利用後のパスワード変更が自動的に実施可能 | |
8.5次のように、グループ、共有、または汎用のIDやパスワード、または他の認証方法が使用されていない。
| ||
8.5.1サービスプロバイダ用の追加要件:（POSシステムやサーバーのサポートのために）顧客環境へのリモートアクセス権を持つサービスプロバイダは、各顧客環境に一意な認証情報（パスワード/パスフレーズなど）を使用する必要がある。 注:この要件は、複数顧客環境がホストされている共有ホスティングプロバイダ自身のホスティング環境に適用されることは意図されていません。 | <パスワードポリシー機能>各システムに一意のパスワードを設定可能 | |
| 8.5.2： パスワード リセットの実行前にユーザーの身元を検証 | ||
| 8.5.4： 解除されたユーザーによるアクセスを即時に無効にする | <ユーザー機能>ユーザーの権限を無効化することで、システム利用の制限が可能 ログイン中は、強制ログアウトが行えないためPMPの再起動により対応が可能 | |
| 8.5.5：90日以上非アクティブなユーザーを削除する | <レポート機能>非アクティブなユーザーとそのパスワードへのアクセス情報（90日間ログインが無い）をリストアップすることが可能 | |
| 8.5.8： グループ/共有/ジェネリックなアカウントとパスワードを使用しない | <パスワードポリシー機能>ポリシーにより、複雑なパスワードの設定およびポリシーを違反しているアカウントのリストアップが可能 | |
| 8.5.9： 最長でも90日以内にユーザーのパスワードを変更する | <レポート機能>指定した日数のパスワードが変更されていないアカウントのリストアップが可能 リストアップ後、一括でパスワード変更が可能 | |
| 8.5.10： 最短パスワード長として7文字以上を要件 | <パスワードポリシー機能>パスワードを設定する際に、最短パスワード長を7文字に設定可能 | |
| 8.5.11： 数字とアルファベットの両方を含むパスワードを使用する | <パスワードポリシー機能>パスワードを設定する際に、数字とアルファベットの両方を含むように設定可能 | |
| 8.5.12： 過去4回分のパスワードのいずれかと同じ新しいパスワードの設定を個人に許可しない | <パスワードポリシー機能>パスワードポリシーを設定する際に、過去4回分のパスワードと同じパスワードが設定されないよう制限可能 | |
8.6他の認証メカニズムが使用されている場合（物理または論理セキュリティトークン、スマートカード、証明書など）、そのメカニズムの使用は次のように割り当てられている。
| ||
8.7カード会員データを含むデータベースへのすべてのアクセス（アプリケーション、管理者、およびその他のすべてのユーザによるアクセスを含む）が以下のように制限されている。
| ||
| 8.8識別と認証に関するセキュリティポリシーと操作手順が文書化されて使用されており、影響を受ける関係者全員に知られていることを確認する。 |
| |
| 要件9:カード会員データへの物理アクセスを制限する | |
| 9.1適切な施設入館管理を使用して、カード会員データ環境内のシステムへの物理アクセスを制限および監視する。 | |
9.1.1ビデオカメラまたはその他のアクセス制御メカニズム（あるいはその両方）を使用して、秘密性の高い領域への個々の物理アクセスを監視する。収集されたデータを確認し、その他のエントリと相関付ける。法律によって別途定められていない限り、少なくとも3カ月間保管する。 注:「機密エリア」とは、データセンタ、サーバルーム、またはカード会員データを保存、処理、または伝送するシステムが設置されているエリアのことである。これには、小売店のレジなど、POS端末のみが存在するエリアは含まれない。 | |
9.1.2物理/論理制御を実施することで、誰でもアクセス可能なネットワークジャックへのアクセスを制限する。 たとえば、公共の場や訪問者がアクセス可能なエリアにあるネットワークジャックは、無効にしておき、ネットワークへのアクセスが明示的に承認されている場合にのみ有効にすることができる。または、アクティブなネットワークジャックがあるエリアでは訪問者に常に同行者をつけるプロセスを実施できる。 | |
9.1.3ワイヤレスアクセスポイント、ゲートウェイ、ハンドヘルドデバイス、ネットワーク/通信ハードウェア、および電気通信回線への物理アクセスを制限する。 | |
9.2次のようにオンサイト要員と訪問者を容易に区別できるような手順を開発する。
| |
9.3オンサイト要員の機密エリアへの物理アクセスを次のように制御する。
| |
9.4訪問者を識別し、承認する手順を実施する。 手順には、以下を含める必要がある。 | |
9.4.1訪問者は、カード会員データが処理または保守されているエリアに入る前に承認が行われ、そのエリアにいる間ずっと同行者に付き添われている。 | |
9.4.2訪問者は識別され、有効期限があり、目視でオンサイト関係者と区別できるバッジその他のIDが与えられる。 | |
9.4.3施設を出る前、または期限が切れる日にバッジその他のIDの返還を求められる。 | |
9.4.4訪問者ログを使用して、カード会員データの保存または送信が行われているコンピュータルームやデータセンターなどの施設への訪問者の行動の物理的監査証跡を保持する。 訪問者の名前、所属会社、物理アクセスを承認したオンサイト要員をログに記録する。 法律によって別途定められていない限り、このログを少なくとも3カ月間保管する。 | |
9.5すべての媒体を物理的にセキュリティ保護する。 | |
9.5.1メディアバックアップを安全な場所に保管する（代替またはバックアップサイト、商用ストレージ施設などのオフサイト施設が望ましい）。保管場所のセキュリティを少なくとも年に一度確認する。 | |
9.6次の項目を含め、あらゆるタイプの媒体を内部または外部に配布する際の厳格な管理を維持する。 | |
9.6.1データの機密性を識別できるように、媒体を分類する。 | |
9.6.2安全な配達業者または正確に追跡することができるその他の方法によって媒体を送付する。 | |
9.6.3安全なエリアから移動されるすべての媒体を管理者が承認していることを確認する（媒体が個人に配布される場合を含む）。 | |
9.7媒体の保管およびアクセスについて、厳密な管理を維持する。 | |
9.7.1すべての媒体の在庫ログを保持し、少なくとも年に一度、媒体の在庫調査を実施する。 | <デバイス管理機能> USBデバイスログを含む、ハードウェアデバイスに対する利用ログを保持し、エクスポートが可能 |
9.8次のように、ビジネスまたは法律上不要になった媒体を破棄する。 | |
9.8.1カード会員データを再現できないよう、ハードコピー資料を裁断、焼却、またはパルプ化する。破棄する資料を保管する容器を安全に保護する。 | |
9.8.2カード会員データを再現できないよう、電子媒体上のカード会員データを回復不能にする。 | |
9.9カードの物理的な読み取りによってペイメントカードデータを取り込むデバイスを改ざんや不正置換から保護する。 注:この要件には、カード（カードのスワイプやディップ）によるトランザクションに使用されるカード読み取り装置も含まれる。この要件は、コンピュータのキーボードやPOSのキーパッドのような手動キー入力コンポーネントには適用されない。 | |
9.9.1装置の最新リストを保持する。リストには以下を含める必要がある。
| |
9.9.2定期的に装置の表面を検査して改ざん（カードスキマーの取り付けなど）や不正置換（連番など装置の特性を調べて偽の装置に差し替えられていないことを確認する）を検出する。 注:装置が改ざんされたり不正置換された兆候の例としては、予期していない付着物やケーブルが装置に差し込まれている、セキュリティラベルが無くなっていたり、変更されている、ケースが壊れていたり、色が変わっている、あるいは連番その他の外部マーキングが変更されているなどがある。 | |
9.9.3関係者が装置の改ざんや不正置換の試みを認識できるようにトレーニングを実施する。トレーニングには以下を含める必要がある。
| |
9.10カード会員データへのアクセスを制限するためのセキュリティポリシーと操作手順が文書化されて使用されており、影響を受ける関係者全員に知られていることを確認する。 |
|
|
| |
| 要件10:ネットワークリソースおよびカード会員データへのすべてのアクセスを追跡および監視する | |||
| 10.1システムコンポーネントへのすべてのアクセスを各ユーザにリンクする監査証跡を確立する | <レポート機能> Firewallを通過したアクセス記録が可能 ユーザーは送信元IPアドレスまたはユーザー認証により識別が可能 | <レポート機能・検索機能・コンプライアンスレポート機能>ユーザーがアクセスした内容の確認が可能 | <レポート機能>ユーザに共有したシステムの確認が可能 |
| 10.2次のイベントを再現するために、すべてのシステムコンポーネントの自動監査証跡を実装する。 | <レポート機能・検索機能・コンプライアンスレポート機能>ログに出力した証跡の確認が可能 | ||
| 10.2.1カード会員データへのすべての個人アクセス | <レポート機能> Firewallを通過したアクセス記録が可能 ユーザーは送信元IPアドレスまたはユーザー認証により識別が可能 | <レポート機能・検索機能・コンプライアンスレポート機能>ログに出力した証跡の確認が可能 | |
| 10.2.2ルート権限または管理権限を持つ個人によって行われたすべてのアクション | <レポート機能>管理ユーザーアクションレポートにより確認が可能 <レポート機能・検索機能・コンプライアンスレポート機能>ログに出力した証跡の確認が可能 | ||
| 10.2.3すべての監査証跡へのアクセス | <レポート機能> Firewallを通過したアクセス記録が可能 ユーザーは送信元IPアドレスまたはユーザー認証により識別が可能 | <レポート機能>ユーザーログオンレポートにより確認が可能 <レポート機能・検索機能・コンプライアンスレポート機能>ログに出力した証跡の確認が可能 | |
| 10.2.4無効な論理アクセス試行 | <レポート機能>セキュリティレポートで確認 拒否ログにより識別が可能 | <レポート機能>ログオン失敗や無効なパスワード、ユーザー名による失敗の検知が可能 <レポート機能・検索機能・コンプライアンスレポート機能>ログに出力した証跡の確認が可能 | |
| 10.2.5識別と認証メカニズムの使用および変更（新しいアカウントの作成、特権の上昇を含むがこれらに限定されない）、およびアカウントの変更、追加、削除のすべてはルートまたは管理者権限が必要である。 | <レポート機能>ユーザー作成、削除、変更、セキュリティグループへのメンバー追加、拡張属性の変更を確認可能 <レポート機能・検索機能・コンプライアンスレポート機能>ログに出力した証跡の確認が可能 | ||
| 10.2.6監査ログの初期化、停止、一時停止 | <レポート機能>プロファイル別レポート(システム監査ログのクリアを監査中)にて確認が可能 <コンプライアンスレポート機能>削除された監査ログの確認が可能 | ||
| 10.2.7システムレベルオブジェクトの作成および削除 | <レポート機能>ファイルの作成、変更、削除を確認可能 <レポート機能・検索機能・コンプライアンスレポート機能>レポートによって作成、削除の確認が可能 | ||
| 10.3イベントごとに、すべてのシステムコンポーネントについて少なくとも以下の監査証跡エントリを記録する。 | <レポート機能>各レポートおよび検索機能によりデータの確認が可能 | ||
| 10.3.1ユーザ識別 | <レポート機能>全てのレポートで確認が可能 <レポート機能>各レポートおよび検索機能によりデータの確認が可能 | ||
| 10.3.2イベントの種類 | <レポート機能>全てのレポートで確認が可能 <レポート機能>各レポートおよび検索機能によりデータの確認が可能 | ||
| 10.3.3日付と時刻 | <レポート機能>全てのレポートで確認が可能 <レポート機能>各レポートおよび検索機能によりデータの確認が可能 | ||
| 10.3.4成功または失敗を示す情報 | <レポート機能>全てのレポートで確認が可能 <レポート機能>各レポートおよび検索機能によりデータの確認が可能 | ||
| 10.3.5イベントの発生元 | <レポート機能>全てのレポートで確認が可能 <レポート機能>各レポートおよび検索機能によりデータの確認が可能 | ||
| 10.3.6影響を受けるデータ、システムコンポーネント、またはリソースのIDまたは名前。 | <レポート機能>全てのレポートで確認が可能 <レポート機能>各レポートおよび検索機能によりデータの確認が可能 | ||
10.4時刻同期技術を使用してすべての重要なシステムクロックおよび時間を同期し、時間を取得、配布、保存するために以下の要件が実施されていることを確認する。 注:ネットワークタイムプロトコル（NTP）は、時刻同期技術の一例である。 | |||
| 10.4.1重要なシステムが正確で一貫性のある時刻を持っている。 | |||
| 10.4.2時刻データが保護されている。 | |||
| 10.4.3時刻設定は、業界で認知されている時刻ソースから受信されている。 | |||
| 10.5変更できないよう監査証跡をセキュリティで保護する。 | |||
| 10.5.1仕事関連のニーズを持つ個人に監査証跡の表示を制限する。 | <権限設定機能> ADAudit Plusの利用ユーザーへの参照権限を制限することで限定した情報のみを確認可能 <ユーザー機能>技術者の設定により、表示可能なホストグループ(Windows,Linux,任意のグループなど)の制限が可能 | <役割機能>特定のユーザのみに監査証跡を表示可能 | |
| 10.5.2監査証跡ファイルを不正な変更から保護する。 | <アーカイブ機能>取得したログを改変できない形式で保存が可能 | <データ保存機能>改変が不可な状態で暗号化し監査証跡を保存可能 | |
| 10.5.3監査証跡ファイルは、変更が困難な一元管理ログサーバまたは媒体に即座にバックアップする。 | <ログ取得機能>イベントログをADAudit Plusがリアルタイムに取得することで、サーバー内でイベントログをクリアしても外部でのイベント記録が可能 また、複数サーバーの情報を一元管理可能 <アーカイブ機能> ・収集したログはテキスト形式で保存される ・オプション[アーカイブデータの暗号化]を有効にすることで、アーカイブ時にファイルの中身を暗号化した状態で保存することができ、テキストファイルの中身が容易に書き換えられることを防止することが可能 | ||
| 10.5.4外部に公開されているテクノロジのログを、安全な一元管理の内部ログサーバまたは媒体デバイス上に書き込む。 | <ログ取得機能>ドメインコントローラー、メンバーサーバーのセキュリティイベントを一元管理が可能 <レポート機能> Windowsホスト、あるいはSyslog対応機器の場合は、レポート機能・検索機能により実現可能 | ||
| 10.5.5ログに対してファイル整合性監視または変更検出ソフトウェアを使用して、既存のログデータを変更すると警告が生成されるようにする（ただし、新しいデータの追加は警告を発生させない）。 | <アラート機能>サーバー上の監査ログがクリアされた際に、アラート機能により管理者へ通知が可能 | ||
| 10.6すべてのシステムコンポーネントのログとセキュリティイベントを調べ、異常や怪しい活動を特定する。 | <アラート機能>アラート設定が可能(重要度の高いイベントに対する22のアラートプロファイルを定義済み) <アラート機能>定義した条件によりアラート通知が可能 | ||
10.6.1毎日一度以上以下をレビューする
| <レポート機能>レビュー用として各種レポート出力での対応が可能 | <スケジュールレポート機能>設定した条件に基づくログ情報を出力するようスケジュール設定を行うことが可能 <ケジュール機能>収集ログ(Windowsホスト・Syslog対応機器・一部アプリケーションログが対象)に対して、設定した条件に基づくログ情報を出力するようスケジュール設定が可能 | |
| 10.6.2組織のポリシー、および年間リスク評価によって決定されたリスク管理戦略に基づいて他のシステムコンポーネントすべてのログを定期的にレビューする。 | <技術者の監査機能>「誰が・いつ・どのレポートを表示/エクスポートしたのか」といった情報を表示することができ、レビューの有無を確認可能 | ||
| 10.6.3レビュープロセスで特定された例外と異常をフォローアップする。 | |||
| 10.7監査証跡の履歴を少なくとも1年間保持し、少なくとも3カ月はすぐに分析できる状態にしておく（オンライン、アーカイブ、バックアップから復元可能など）。 | <アーカイブ機能>アーカイブ機能およびDBの保存期間設定にて保存期間の設定が可能 | <アーカイブ機能>イベントのアーカイブを行なうことにより外部保管が可能 また、アーカイブ済みイベントを復元することで、検索表示が可能 <アーカイブ機能>表示可能な期間および保存期間の設定が可能 | <監査保管機能>監査機能の設定にて、保存期間の設定が可能 |
10.8サービスプロバイダ用の追加要件:以下の重要なセキュリティ管理システム（ただし、これらに限定されない）の障害をタイムリーに検出し報告するプロセスを実装する。
注:この要件は、2018年1月31日まではベストプラクティスとみなされ、それ以降は要件になる。 | <アラート機能>閾値を設定することにより、イベント発生時に管理者へメール通知が可能 | ||
10.8.1サービスプロバイダ用の追加要件:重要なセキュリティコントロールの失敗にタイムリーに対応する。セキュリティコントロールの失敗に対処するためのプロセスには以下のようなものがあります。
注:この要件は、2018年1月31日まではベストプラクティスとみなされ、それ以降は要件になる。 | |||
| 10.9ネットワークリソースとカード会員データへのすべてのアクセスを監視するためのセキュリティポリシーと操作手順が文書化され、使用されており、影響を受ける関係者全員に知られていることを確認する。 |
| |
| 要件11:セキュリティシステムおよびプロセスを定期的にテストする | |
11.1四半期ごとにワイヤレスアクセスポイントの存在をテストし（802.11）、すべての承認されているワイヤレスアクセスポイントと承認されていないワイヤレスアクセスポイントを検出し識別するプロセスを実施する。 注:プロセスで使用される方法には、ワイヤレスネットワークのスキャン、システムコンポーネントおよびインフラストラクチャの論理的/物理的な検査、ネットワークアクセス制御（NAC）、無線IDS/IPSが含まれるがこれらに限定されるわけではない。いずれの方法を使用する場合も、承認されているデバイスと承認されていないデバイスを両方検出および識別できる機能を十分に備えている必要がある。 | |
| 11.1.1文書化されている業務上の理由を含め、承認されているワイヤレスアクセスポイントのインベントリを維持する。 | |
| 11.1.2不正なワイヤレスデバイスが検出された場合のインシデント対応計画を実装する。 | |
11.2内部と外部ネットワークの脆弱性スキャンを少なくとも四半期に一度およびネットワークでの大幅な変更（新しいシステムコンポーネントのインストール、ネットワークトポロジの変更、ファイアウォール規則の変更、製品アップグレードなど）後に実行する。 注:四半期ごとのスキャンプロセスの複数のスキャンレポートをまとめて、すべてのシステムがスキャンされ、該当するすべての脆弱性に対処されたことを示すことができる。未修正の脆弱性が対処中であることを確認するために、追加の文書が要求される場合がある。 評価者が1）最新のスキャン結果が合格スキャンであったこと、2）事業体で四半期に一度のスキャンを要求するポリシーと手順が文書化されていること、および3）スキャン結果で判明した脆弱性が再スキャンにおいて示されているとおりに修正されたことを確認した場合、初回のPCI DSS準拠のために、四半期に一度のスキャンに4回合格することは要求されない。初回PCI DSSレビュー以降は毎年、四半期ごとのスキャンに4回合格しなければならない。 | |
| 11.2.1四半期ごとの内部脆弱性スキャンを実施する。脆弱性に対応し、事業体の脆弱性ランキング（要件6.1参照）に従ってすべての「高リスク」脆弱性が解決されたことを検証するために再スキャンを実施する。スキャンは有資格者が実施する必要がある。 | <パッチ管理機能> OSに適用されていないパッチ一覧の表示が可能。 ※脆弱性レベルは、システムの脆弱性レベルや、不足しているアプリケーションのパッチ、タスクのステータスなどの情報に基づき算出 |
11.2.2四半期に一度の外部の脆弱性スキャンは、ペイメントカード業界（PCI）セキュリティ基準審議会（PCI SSC）によって資格を与えられた認定スキャニングベンダ（ASV）によって実行される必要がある。スキャンに合格するまで、必要に応じて再スキャンする。 注:四半期に一度の外部の脆弱性スキャンは、PCI（Payment Card Industry）セキュリティ基準審議会（PCI SSC）によって資格を与えられた認定スキャニングベンダ（ASV）によって実行される必要がある。スキャンにおける顧客の責任、スキャンの準備などについては、PCI SSC Webサイトで公開されている『ASVプログラムガイド』を参照してください。 | |
| 11.2.3大幅な変更後、必要に応じて内部と外部のスキャン、再スキャンを実施する。スキャンは有資格者が実施する必要がある。 | |
11.3以下を含むペネトレーションテスト方法を実装する。
| |
| 11.3.1外部のペネトレーションテストを少なくとも年に一度および大幅なインフラストラクチャまたはアプリケーションのアップグレードや変更（オペレーティングシステムのアップグレード、環境へのサブネットワークの追加、環境へのWebサーバの追加など）後に実行する。 | |
| 11.3.2内部ペネトレーションテストを少なくとも年に一度および大幅なインフラストラクチャまたはアプリケーションのアップグレードや変更（オペレーティングシステムのアップグレード、環境へのサブネットワークの追加、環境へのWebサーバの追加など）後に実行する。 | |
| 11.3.3ペネトレーションテストで検出された悪用可能な脆弱性が修正され、テストが繰り返されて修正が確認される。 | |
| 11.3.4セグメンテーションを用いてCDEを他のネットワークから分離した場合、少なくとも年に一度とセグメンテーションの制御/方法が変更された後にペネトレーションテストを行って、セグメンテーション方法が運用可能で効果的であり、CDE内のシステムから適用範囲外のシステムをすべて分離することを確認する。 | |
| 11.3.4.1サービスプロバイダ用の追加要件:セグメンテーションが使用されている場合は、少なくとも6か月に一度とセグメンテーションの制御/方法が変更された後にセグメンテーション制御のペネトレーションテストを行ってPCI DSSスコアを確認する。 注:この要件は、2018年1月31日まではベストプラクティスとみなされ、それ以降は要件になる。 | |
| 11.4侵入を検出/防止するための侵入検出/侵入防止技法をネットワークに組み込む。カード会員データ環境との境界およびカード会員データ環境内の重要なポイントを通過するすべてのトラフィックを監視し、侵害の疑いがある場合は担当者に警告する。 すべての侵入検知および防止エンジン、ベースライン、シグネチャを最新状態に保つ。 | |
11.5変更検出メカニズム（ファイル整合性監視ツールなど）を導入して重要なシステムファイル、構成ファイル、またはコンテンツファイルの不正な変更（変更、追加、削除を含む）を担当者に警告し、重要なファイルの比較を少なくとも週に一度実行するようにソフトウェアを構成する。 注:変更検出目的で、重要なファイルとは通常、定期的に変更されないが、その変更がシステムの侵害や侵害のリスクを示す可能性があるファイルを示す。ファイル整合性監視製品などの変更検出メカニズムでは通常、関連オペレーティングシステム用の重要なファイルがあらかじめ構成されている。カスタムアプリケーション用のファイルなど、その他の重要なファイルは、事業体（つまり、加盟店またはサービスプロバイダ）による評価および定義が必要である。 | |
| 11.5.1変更検出ソリューションによって生成された警告に対応するプロセスを実装する。 | |
| 11.6セキュリティ監視とテストに関するセキュリティポリシーと操作手順が文書化されて使用されており、影響を受ける関係者全員に知られていることを確認する。 |
|
| |
| 要件12:すべての担当者の情報セキュリティポリシーを整備する | ||
| 12.1セキュリティポリシーを確立、公開、維持、普及させる。 | ||
| 12.1.1少なくとも年に一度レビューし、環境が変更された場合にポリシーを更新する。 | ||
12.2次のリスク評価プロセスを実装する。
リスク評価方法の例としては、OCTAVE、ISO 27005、およびNIST SP 800-30が挙げられますが、これらに限定されません。 | <パッチ管理およびレポート機能>脆弱性スキャンとパッチ管理が可能 また、スキャン結果の参照が可能であり、それにより脅威の特定や変更の把握が可能 | <レポート機能>システム上の利用者状況やシステムのパスワード変更状況を確認可能 |
12.3重要なテクノロジに関する使用ポリシーを作成して、これらのテクノロジの適切な使用を定義する 注:重要なテクノロジの例には、リモートアクセスおよびワイヤレステクノロジ、ノートパソコン、タブレット、リムーバブル電子媒体、電子メールの使用、インターネットの使用がありますが、これらに限定されません これらの使用ポリシーで以下を要求することを確認する。 | <ポリシー設定機能>パスワードの設定や、カメラ・Youtube・Safariなどの使用を制限するためのポリシー定義が可能 また、メール、Wi-Fi、VPNなどの会社アカウントへのアクセス許可設定が可能 | |
| 12.3.1権限を持つ関係者による明示的な承認 | ||
| 12.3.2テクノロジの使用に対する認証 | ||
| 12.3.3このようなすべてのデバイスおよびアクセスできる担当者のリスト | ||
| 12.3.4デバイスの所有者、連絡先情報、目的を正確にその場で識別できる方法（ラベル付け、コーディング、デバイスのインベントリ） | <インベントリ管理機能>ネットワークから、ハードウェアとソフトウェアの包括的な情報を収集することが可能 ※収集する情報としては、メモリ、OS、製造元、デバイスタイプなどが含まれ、またソフトウェアの場合はブラックリストアプリケーション、ライセンスコンプライアンスなどを含む | |
| 12.3.5テクノロジの許容される利用法 | ||
| 12.3.6テクノロジの許容されるネットワーク上の場所 | ||
| 12.3.7会社が承認した製品のリスト | ||
| 12.3.8非アクティブ状態が特定の期間続いた後のリモートアクセステクノロジのセッションの自動切断 | <リモート制御機能>アイドルセッション設定から可能 ※リモートセッションの最大アイドル時間を設定することができ、設定したアイドル時間を超過した場合は、セッションを自動的に切断およびロック可能 | |
| 12.3.9ベンダおよびビジネスパートナーには必要とする場合にのみリモートアクセステクノロジをアクティブ化し、使用後直ちに非アクティブ化する | <ユーザー管理機能>必要なトラブルシューティングやセッションの終了後、セッションを非アクティブとする設定が可能 | |
12.3.10リモートアクセステクノロジ経由でカード会員データにアクセスする担当者については、定義されたビジネスニーズのために明示的に承認されていない限り、ローカルハードドライブおよびリムーバブル電子媒体へのカード会員データのコピー、移動、保存を禁止する。 承認されたビジネスニーズがある場合、使用ポリシーはデータが適用されるPCI DSS要件すべてに従って保護されることを要求する必要がある。 | ||
| 12.4セキュリティポリシーと手順が、すべての担当者に関する情報セキュリティ責任を明確に定義していることを確認する。 | ||
12.4.1サービスプロバイダ用の追加要件:エグゼクティブマネジメンによってカード会員データの保護およびPCI DSS準拠プログムの責任を明確化する。次の項目を含む。
注:この要件は、2018年1月31日まではベストプラクティスとみなされ、それ以降は要件になる。 | ||
| 12.5個人またはチームに以下の情報セキュリティの責任を割り当てる。 | <共有機能>管理者ごとの管理対象特権IDの割り当てが可能 | |
| 12.5.1セキュリティポリシーおよび手続きを確立、文書化、配布する。 | <パスワードポリシー機能>パスワードポリシーの設定により、ポリシーに従ったパスワードの設定が実現可能 | |
| 12.5.2セキュリティの警告や情報を監視および分析し、適切な担当者に配布する。 | <アナウンス機能> IT管理者は、適切なユーザーに対して情報配布が可能 | <監査通知機能>指定したインシデント発生時に、syslog機能やSNMPトラップ機能を使用した通知が可能 |
| 12.5.3セキュリティインシデントの対応およびエスカレーション手順を確立、文書化、配布し、すべての状況にタイムリーかつ効率的に対処することを確認する。 | <監査通知機能>指定したインシデント発生時に、syslog機能やSNMPトラップ機能を使用した通知が可能 | |
| 12.5.4追加、削除、変更を含め、ユーザアカウントを管理する。 | <ユーザー管理機能> RBAC（役割ベースアクセスコントロール機能）から、役割の作成・変更・削除が可能 | <ユーザー管理機能> RBAC（役割ベースアクセスコントロール機能）から、役割の作成・変更・削除が可能 |
| 12.5.5すべてのデータへのアクセスを監視および管理する。 | <デバイス管理機能> USBなどのメディアデバイスの使用制限が可能 | <監査通知機能>監査機能により、ユーザー利用状況を監視することが可能 管理者により、システムを使用するユーザー管理が可能 |
| 12.6カード会員データセキュリティポリシーおよび手順を全担当者が認識できるように正式なセキュリティ意識向上プログラムを実装する。 | ||
| 12.6.1担当者の教育を採用時および少なくとも年に一度行う。 注:方法は、担当者の役割とカード会員データへのアクセスレベルに応じて異なる。 | ||
| 12.6.2担当者は、少なくとも年に一度セキュリティポリシーおよび手順を読み、理解したことを認める必要がある。 | ||
12.7雇用する前に、可能性のある担当者を選別して、内部ソースからの攻撃リスクを最小限に抑える。（バックグラウンドチェックの例には、職歴、犯罪歴、信用履歴、経歴照会がある。） 注:このような可能性のある担当者を、トランザクションの実施で一度に1つのカード番号にしかアクセスできないようなレジ係など、特定の役職に採用する場合は、この要件は推奨のみです。 | ||
| 12.8カード会員データを共有するサービスプロバイダ、またはカード会員データのセキュリティに影響を及ぼす可能性のあるサービスプロバイダについて、次の項目を含め、そのサービスプロバイダを管理するポリシーと手順を維持および実装する。 | ||
| 12.8.1提供するサービスの記載を含むサービスプロバイダのリストを維持する。 | ||
12.8.2サービスプロバイダが自社の所有する、または顧客に委託されて保管、処理、伝送する、あるいは顧客のカード会員データ環境の安全に影響を及ぼすような、カード会員データのセキュリティに対して責任を負うことに同意した、書面での契約が維持されている。 注:同意の正確な言葉づかいは、両当事者間の同意事項、提供サービスの詳細、各当事者に割り当てられた責任によって異なります。同意には、この要件に記載されているのとまったく同じ言葉づかいを含める必要はありません。 | ||
| 12.8.3契約前の適切なデューデリジェンスを含め、サービスプロバイダとの契約に関するプロセスが確立されている。 | ||
| 12.8.4少なくとも年に一度、サービスプロバイダのPCI DSS準拠ステータスを監視するプログラムを維持する。 | ||
| 12.8.5どのPCI DSS要件がそれぞれのサービスプロバイダにより管理され、どの要件が対象の事業体により管理されるかについての情報を維持する。 | ||
12.9サービスプロバイダ用の追加要件:サービスプロバイダが自社の所有する、または顧客に委託されて保管、処理、伝送する、あるいは顧客のカード会員データ環境の安全に影響を及ぼすような、カード会員データのセキュリティに対して責任を負うことに同意している。 注:同意の正確な言葉づかいは、両当事者間の同意事項、提供サービスの詳細、各当事者に割り当てられた責任によって異なります。同意には、この要件に記載されているのとまったく同じ言葉づかいを含める必要はありません。 | <監査通知機能>指定したインシデント発生時に、syslog機能やSNMPトラップ機能を使用した通知が可能 | |
| 12.10インシデント対応計画を実施する。システム違反に直ちに対応できるよう準備する | ||
12.10.1システム違反が発生した場合に実施されるインシデント対応計画を作成する。計画では、最低限、以下に対応する。
| ||
| 12.10.2要件12.10.1に列挙されたすべての要素を含むテストプランの見直しを、少なくとも年に一度行う。 | ||
| 12.10.3警告に24時間365日体制で対応できる担当者を指定する。 | ||
| 12.10.4セキュリティ違反への対応を担当するスタッフに適切なトレーニングを提供する。 | ||
| 12.10.5侵入検知、侵入防止、ファイアウォール、ファイル整合性監視システムを含むがこれらに限定されない、セキュリティ監視システムからの警告を含める。 | ||
| 12.10.6得られた教訓を踏まえてインシデント対応計画を変更および改善し、業界の発展を組み込むプロセスを作成する。 | ||
12.11サービスプロバイダ用の追加要件:少なくとも四半期に一度、担当者がセキュリティポリシーと操作手順を遵守しているかの見直しを行う。見直しには以下のプロセスを含める必要がある。
注:この要件は、2018年1月31日まではベストプラクティスとみなされ、それ以降は要件になる。 | ||
12.11.1サービスプロバイダ用の追加要件:以下の項目を含む四半期見直しプロセスの文書を整備する。
注:この要件は、2018年1月31日まではベストプラクティスとみなされ、それ以降は要件になる。 |
| 付録A1:共有ホスティングプロバイダ向けのPCI DSS追加要件 |
A1各事業体（加盟店、サービスプロバイダ、またはその他の事業体）のホスト環境とデータを、A.1.1〜A.1.4に従って保護する。 ホスティングプロバイダは、これらの要件およびPCI DSSのその他すべての関連セクションを満たす必要があります。 注:ホスティングプロバイダがこれらの要件を満たすことができたとしても、そのホスティングプロバイダを使用する事業体の準拠が保証されるわけではありません。各事業体は、PCI DSSに従い、準拠を適宜検証する必要があります。 |
| A1.1各事業体が、その事業体のカード会員データ環境にアクセスするプロセスのみを実行するようにする。 |
| A1.2各事業体のアクセスおよび特権が、その事業体のカード会員データ環境のみに制限されている。 |
| A1.3ログ記録と監査証跡が有効になっていて、各事業体のカード会員データ環境に一意であり、PCI DSS要件10と一致していることを確認する。 |
| A1.4ホストされている加盟店またはサービスプロバイダへの侵害が発生した場合に、タイムリーなフォレンジック調査を提供するプロセスを可能にする。 |
付録A2: SSL/early TLSを使用している事業体向けのPCI DSS追加要件 注:この付録はCDEまたはCHDを保護するためにSSL/early TLSをセキュリティ制御として使用している事業体に適用されます。 |
A2.1 POS POI端末（および接続先のSSL/TLSターミネーションポイント）がSSL/early TLSを使用している場合、事業体は以下の両方の条件を満たす必要があります。
または:
|
| A2.2既存の実装（A2.1で許可された以外）のある事業体がSSL/early TLSを使用している場合は、正式なリスク緩和および緩和計画が整備されている必要がある。 |
A2.3サービスプロバイダ用の追加要件:すべてのサービスプロバイダは、2016年6月30日までに、安全なサービス提供を行うようにする必要があります。 注: 2016年6月30日までは、サービスプロバイダは自ら提供するサービスに安全なプロトコルのオプションを含めるか、または文書化したリスク緩和および緩和計画(A2.2参照)に2016年6月30日以前に設定した安全なプロトコルオプション提供の目標期日を含める必要があります。この期日以降は、すべてのサービスプロバイダは自らのサービスに安全なプロトコルのオプションを提供する必要があります。 |