Comments
Description
Transcript
PCI セキュリティ監査手順
VISA ／ JCB PCI セキュリティ監査手順 バージョン 1.0 この資料は、 『PCI セキュリティ監査手順』を理解するために、 Visa International 東京事務所および JCB が試訳した参考資料 です。この資料は正式な Visa および JCB の業務文書ではありま せ ん 。 正 は 英 語 版 の 「 Payment Security Audit Procedures Version 1.0 December 2004」とします。万一、本文書と英語版 （原本）に翻訳、解釈の相違があった場合は英語版が優先され ます。 2004 年 12 月 免責 『PCI セキュリティ監査手順』は、Visa および JCB のカード情報を格納、処理、または伝送するすべての 事業者が PCI データ・セキュリティスタンダード（以下 PCI 基準）を満たすための「ガイドライン」として使用 される。ただし、Visa Asia Pacific および JCB は、セキュリティ侵害または損害が発生した場合であって も、監査手順が実施されているかどうかに関わらず、何ら責任または義務を負うものではない。 注意事項 『PCI セキュリティ監査手順』は、Visa Asia Pacific および JCB のカード情報セキュリティ（AIS）文書の 一部である。Visa Asia Pacific および JCB のメンバー金融機関およびそのエージェント（加盟店とサー ビス・プロバイダ）は、必ず PCI 基準に従って、カード会員情報を処理、格納、伝送しなければならない。 Visa Asia Pacific の AIS プログラムの詳細に関しては、http://www.visa-asia.com/secured を参照の こと。 JCB の AIS プログラムの詳細に関しては http://www.jcb-global.com/ を参照のこと。 日本語翻訳 バージョン 更新日付 1.0 2005 年６月１日 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 PCI セキュリティ監査手順 本書は、PCI 基準への準拠を確認し、『準拠に関するレポート』を作成するためのオンサイト・レビューを必要とする加盟店とサービス・プロバイダによって使用される。 PCI 基準は、カード会員情報を格納、処理、または伝送するすべてのメンバー金融機関、加盟店、サービス・プロバイダに適用される。また、これらのセキュリティ要件は、 カード会員情報環境内に存在するか接続されるネットワーク・コンポーネント、サーバー、アプリケーションとして定義されるすべての「システム・コンポーネント」に適用され る。ネットワーク・コンポーネントには、ファイアウォール、スイッチ、ルーター、無線アクセス・ポイント、ネットワーク・アプリケーション、その他のセキュリティ機器などが含まれ るが、それらに限定されない。サーバーには、Web、データベース、認証、DNS、メール、プロキシ、NTP などが含まれるが、それらに限定されない。アプリケーションには、 内部と外部の両方の（Web）アプリケーションを含み、購入したアプリケーションおよび個別開発アプリケーションの両方が含まれる 評価の範囲 毎年のオンサイト・レビューの実施を求められているサービス・プロバイダの場合、特に指定がないかぎり、カード会員情報が処理、格納、または伝送されるすべてのシステ ム・コンポーネントについて、PCI 基準への準拠を確認しなければならない。 毎年のオンサイト・レビューの実施を求められている加盟店の場合、準拠確認の範囲は、カード会員情報が処理、格納、または伝送される認証と決済に関連するシステム またはシステム・コンポーネントが対象となる。これには、次の項目が含まれる。 ● ● ● ● 加盟店のネットワークへのすべての外部接続（例：従業員のリモート・アクセス、カード会社、およびサードパーティへのアクセス）。 オーソリゼーションおよび決済環境間のすべての接続（例：従業員アクセス、またはファイアウォールやルーターなどのデバイスに対する接続）。 50 万（VISA さん宿題）を超えるトランザクションが格納されている、オーソリゼーションおよび決済環境の外にあるデータ・リポジトリ。 POS 端末は除く。ただし、 ● POS 環境が IP ベースで、加盟店へのインターネット、無線、VPN、ダイヤルイン、ブロードバンド、誰でもアクセス可能なマシン（キオスクなど）を通じた外部アクセ スがある場合、POS 環境をオンサイト・レビューの対象としなければならない。 ● POS 環境が、非 IP ベースであるか、加盟店への外部アクセスがない場合、オーソリゼーションおよび決済環境への接続からレビューを開始する。 注：POS 環境とは、トランザクションが加盟店の立地（すなわち、小売店、レストラン、ホテル建物、ガソリンスタンド、スーパーマーケット、その他販売時点（POS）場所）で発 生する環境をいう。IP ベースの POS 環境とは、トランザクションが IP ベースのシステム上または TCP/IP を介して通信するシステム上で格納、処理、または伝送されるよう な環境をいう。 無 線 カード会員情報の伝送、処理、または格納（例：POS トランザクション、ラインバスティング（line-busting）など）に無線技術を使用するか、無線 LAN がカード会員環境に 接続されている、もしくはその一部となっている（例：ファイアウォールによって明確に分離されていない）場合、無線環境に関する「要件」と「テスト手順」も実行しなければ ならない。無線のセキュリティはまだ成熟していないが、これらの要件では、最小限の保護を実現するために、基本的な無線セキュリティ機能の実装を指定している。無線 技術では十分にセキュリティが保てないため、無線技術を導入する場合、事前にその技術の必要性をリスクと照らし合わせて評価することを推奨する。また、非機密データ の伝送のためだけに設置したり、より安全な技術を待つことも考えるべきである。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 1 PCI セキュリティ監査手順 アウトソーシング カード会員情報の処理、伝送、または格納をサードパーティのサービス・プロバイダにアウトソースしている場合、『準拠に関するレポート』で各サービス・プロバイダの役割 を記述しなければならない。ただし、これらのサービス・プロバイダは、その顧客とは無関係に、PCI 基準への準拠の確認に責任を持つ。また、加盟店とサービス・プロバイ ダは、カード会員情報にアクセスする関連するすべてのサードパーティに対して、PCI 基準への準拠を契約により求めなければならない。詳細は本書の 12.8 項を参照の こと。 サンプリング 評価担当者は、テストするシステム・コンポーネントのサンプルを選択することができる。サンプルは、すべてのタイプのシステム・コンポーネントから代表的なものを選択す ることで、レビューする領域に適用されるさまざまなオペレーティング・システム、機能、アプリケーションを含んでいなければならない。たとえば、Apache WWW を実行す る Sun サーバー、Oracle を実行する NT サーバー、従来のカード処理アプリケーションを実行するメインフレーム、HP-UX を実行するデータ転送サーバー、MYSQL を 実行する Linux サーバーなどを選ぶことができる。すべてのアプリケーションが単一の OS（例：NT、Sun など）上で動作している場合も、サンプルには各種のアプリケーシ ョン（例：、データベース・サーバー、Web サーバー、データ転送サーバーなど）が含まれている必要がある。 「システム・コンポーネント」の定義については、本書の最初のページを参照。 準拠に関するレポート 本書は、『準拠に関するレポート』を作成するためのテンプレートとして使用される。アクワイアラ、加盟店、サービス・プロバイダは、カード会社が事業者の準拠状況を認識 できるように、カード会社毎の報告要件に従う必要がある。結果の提出先については、個々のカード会社に問い合わせること。 すべての評価担当者は、『準拠に関するレポート』を作成する際は、次のレポート内容および形式を適用しなければならない。 1. 連絡先とレポート日付 ● 加盟店またはサービス・プロバイダ、および評価担当者の連絡先を記述する。 ● レポートの日付。 2. エグゼクティブ・サマリー 次の項目を記述する。 ● 業務内容。 ● カード会員情報を共有するサービス・プロバイダやその他の事業者のリスト。 ● プロセッサのリスト。 ● 事業者がカード会社と直接接続されているかどうかについて。 ● 加盟店の場合、使用している POS。 ● PCI 基準への準拠を必要とする完全子会社。 ● PCI データ・セキュリティ標準への準拠を必要とする国際事業者。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 2 PCI セキュリティ監査手順 ● カード会員環境と接続された無線 LAN／無線 POS 端末。 3. 作業範囲とアプローチの説明 ● 評価の実施に使用される『セキュリティ監査手順文書』のバージョン。 ● 評価の期間。 ● 評価の対象となった環境（すなわち、クライアントのインターネット・アクセス・ポイント、内部企業ネットワーク、カード会社の処理ポイントなど）。 ● レビューから除外された領域。 ● ネットワーク・トポロジとコントロールの簡単な説明または図。 ● インタビュー相手のリスト。 ● 使用中のハードウェアと重要な（例：データベースまたは暗号化）ソフトウェアのリスト。 ● 管理サービス・プロバイダ（MSP）のレビューの場合、本書のどの要件が MSP に適用され（およびレビューに含まれ）、どれがレビューに含まれず、MSP の顧客が 独自のレビューに含めることになっているかを明確に示す。MSP の四半期毎の脆弱性スキャンでは MSP のどの IP アドレスをスキャンし、どの IP アドレスが MSP の顧客が独自の四半期毎のスキャンに含めることになっているかを記述する。 4. 四半期毎のスキャンの結果 ● 過去 4 回の四半期毎のスキャン結果を要件 11.2 のコメントとして簡単に記述する。 ● スキャンの実施にあたっては、事業者に存在するすべての外部アクセス可能な（インターネットに露出している）IP アドレスをカバーする必要がある。 5. レビュー結果 ● すべての評価担当者は、次のテンプレートを使用して、詳しいレポート記述と、それぞれの要件に関して発見した事項を提供しなければならない。 ● 対応がなされていると判断される代替手段がある場合、それを記述する。代替手段については、次のページの「定義」を参照。 未解決項目の再確認 準拠には、「実施中の対応」レポートが必要である。初期レポートに未解決項目があった場合、事業者は、すべての未解決項目を修正し、評価担当者は、改善が施され、 すべての要件に対処しているかを再評価する。再評価の後、評価担当者は完全に準拠した「準拠に関するレポート」を再作成し、上記の指示に従って提出する必要があ る。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 3 PCI セキュリティ監査手順 定 義 セキュリティ監査手順の目的から、次の定義を使用する。 要 件 評価担当者が事業者の準拠を確認するための PCI 基準の要件。 代替手段 「要件」欄で定義された手段の代替として実施される手段。これらの手段は、評価担当者による審査も受け、評価担当者の意見として、本来 の要件の意図および厳格性を満たす必要がある。代替手段は、他の PCI 要件より高いレベルの要件であり、単に本書の他の要件に準拠し ているだけでは代替手段ではない。 テスト手順 評価担当者が個別の要件およびテスト要素に対応する際に従うべきプロセス。このテスト手順には、評価担当者が要件をサポートするために 検討すべき対応中の詳しい手段をあげる。それらの詳しい手段が記述どおりに対応されていない場合、もしくは技術的または他の制約により 対応できない場合、評価担当者は代替手段を調査する必要がある。 対応 代替手段の結果として対応されていることが確認されたものを含み、対応中であることが確認された手段について簡単に説明する。 未対応 未対応の手段について簡単に説明する。要件が「該当せず（N/A）」の場合、理由を説明する。 目標期日／コメント 「未対応」の手段について、事業者が対応する目標期日を記述する。その他メモまたはコメントを書き込むこともできる。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 4 PCI セキュリティ監査手順 安全なネットワークの構築・維持 要 件 テスト手順 対 応 未対応 目標期日／コメント 要件 1：データを保護するためにファイアウォールを導入し、最適な設定を維持すること ファイアウォールは外部から社内のネットワークへのコンピュータ・トラフィック、および社内ネットワーク内にある、より機密性の高いエリアへのトラフィックを制御する装置で ある。すべてのシステムは電子商取引、従業員のデスクトップ・ブラウザを通じたインターネットへのアクセス、従業員の電子メールによるアクセスなど、どんな用途であって もインターネットからの不正アクセスから保護される必要がある。しばしば、問題ないように思われるインターネットへのアクセス経路が、重要なシステムに対する侵入経路に なっている場合がある。ファイアウォールはあらゆるコンピュータ・ネットワークにとって欠くことのできない保護メカニズムである。 1.1 次のようなファイアウォール導 1.1 手順が完全である証拠を得るために、以下に指定されたファイアウォ 入手順を確立する。 ール導入手順および他の文書を入手し、点検する。また、以下の文書の コピーも入手する。 1.1.1 ファイアウォール導入手順を入手および検証し、外部ネットワーク 1.1.1 すべての外部ネットワー 接続やファイアウォール設定のすべての変更に関する管理権限者の承 ク接続とファイアウォール設定 認およびテストを含む、あらゆる変更について、正式の手続きが用意さ の変更をテスト、検証するため れているかを確認する。 の正式な手続き。 1.1.2 最新のネットワーク図を入手および検証し、無線ネットワークを含 1.1.2 無線ネットワークを含む、 むカード会員情報とのあらゆる接続が記述されており、図が最新の状態 カード会員情報への全接続を に保たれているかを確認する。 あらわした最新のネットワーク 図。 1.1.3 最新のネットワーク図を入手し、各インターネット接続、および 1.1.3 各インターネット接続、お DMZ とイントラネットとの間にファイアウォールが存在することを確認す よび DMZ とイントラネットとの間 る。 にあるファイアウォールの要件。 1.1.4 ファイアウォール導入手順がネットワーク・コンポーネントの論理 1.1.4 ネットワーク・コンポーネ 的管理に関するグループとそれぞれの役割、責務の記述を含んでいる ントの論理管理に関するグルー ことを確認する。 ピングとそれぞれの役割、責務 に関する記述。 1.1.5 業務に必要なサービス 1.1.5 ファイアウォール導入手順が業務に必要なサービス／ポートの文 ／ポートの文書化されたリスト。 書リストを含んでいることを確認する。 1.1.6 ファイアウォール導入手順が HTTP および SSL、SSH、VPN 以 1.1.6 HTTP お よ び SSL 、 外で利用可能なプロトコルに関する正当化理由と文書を含んでいること SSH、VPN 以外で利用可能な を確認する。 プロトコルに関する正当化理由 と文書。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 5 PCI セキュリティ監査手順 安全なネットワークの構築・維持 要 件 1.1.7 危険性のあるプロトコル （FTC など）を許可する場合の 正当化理由と文書。そこにはプ ロトコルの使用理由と実装され るセキュリティ機能が含まれる。 1.1.8 ファイアウォール／ルー ターに関するルール・セットの 定期的なレビュー。 1.1.9 ルーターに関する導入 手順。 1.2 次のものを除くすべての「信 用できない(untrusted)」ネットワ ーク／ホストからの全トラフィックを 拒否するファイアウォール構成を 構築する。 テスト手順 1.1.7 プロトコルを使用したり、セキュリティ機能を実装したりする理由を 含む、ファイアウォール設定が許可されている危険なプロトコル（例： FTP）に関する正当化理由と文書を含んでいることを確認する。使用中 の各サービスが必要で、かつセキュリティが保たれている証拠を得るた めに、サービスに関するドキュメンテーションと設定を検証する。 1.1.8 ファイアウォール導入手順が、ファイアウォール／ルーターに関 するルール・セットの定期的レビューを要求していることを確認する。ル ール・セットが定期的にレビューされている証拠を得る。 1.1.9 ファイアウォール導入手順がファイアウォールとルーターの両方 を含んでいることを確認する。 1.2 1) インターネットと DMZ との間、2) DMZ と内部ネットワークとの間 でファイアウォール／ルーターのサンプルを選択する（サンプル・サイズを 挿入する）。サンプルは、インターネット、DMZ ルーター、ファイアウォー ル、DMZ カード会員セグメント、周辺ルーター、内部のカード会員ネットワ ーク・セグメントにチョーク・ルーターを含んでいる必要がある。すべてのト ラフィックが次のものに制限されているかを確認するために、ファイアウォ ールとルーターの構成を検証する。 1.2.1 Web プロトコル（HTTP、HTTPS）。 1.2.1 Web プロトコル-HTTP(ポ ー ト 80)) と Secure Sockets Layer (SSL) （ 通 常 は ポ ー ト 443）。 1.2.2 システム管理／リモート・アクセス手段（VPN、SSH）。 1.2.2 システム管理プロトコル （例：セキュア・シェル（SSH）ま たはバーチャル・プライベート・ ネットワーク（VPN））。 1.2.3 業務に必要なその他の 1.2.3 業務に必要で、ファイアウォール・ポリシーに文書化されているそ プロトコル（例：ISO 8583）。 の他の許可されたトラフィック。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 対 応 未対応 目標期日／コメント 6 PCI セキュリティ監査手順 安全なネットワークの構築・維持 要 件 テスト手順 1.3 外部からアクセス可能なサーバ 1.3 誰でもアクセス可能なサーバーとカード会員情報を格納したコンポ ーと、カード会員情報を格納するシ ーネントとの間の接続が制限されていることを確認するために、ファイア ステム・コンポーネントとの間の接続 ウォール／ルーターの構成を検証する。 を制限するようなファイアウォールを 構築する。このファイアウォール構成 には、次の項目が含まれている必要 がある。 1.3.1 外部からのトラフィックが DMZ 内の IP アドレスに制限されてい 1.3.1 DMZ 内の IP アドレスへのイ るかを調べる。 ンターネット・ト ラフィックの制限 （ingress フィルタ）。 1.3.2 ポート 80 と 443 経由のイン 1.3.2 すべてのインターネット・トラフィックがポート 80 および 443 に ターネット・トラフィックの制限。 制限されているかを調べる。 1.3.3 インターネットから DMZ 内 へ通過できる内部アドレスの禁止 （egress フィルタ））））））。 1.3.4 ステートフル・インスペクショ ン。動的パケット・フィルタリングと も 呼 ば れる（ネット ワ ーク内 へは 「確立された」接続のみ許す）。 1.3.5 DMZ から分離された内部 ネットワーク・ゾーンにデータベー スを配置する。 1.3.6 決済環境から外部へのトラ フィックを業務上必要最小限まで に制限。 対 応 未対応 目標期日／コメント 1.3.3 インターネットから DMZ へ通過できる内部アドレスが存在して いないかを調べる。 1.3.4 ファイアウォールがステートフル・インスペクション（動的パケッ ト・フィルタリング）を実行するかを調べる。（確立された接続のみ、す なわち前に確立されたセッションと関連している場合のみ許可される べきである（すべての TCP および UDP ポートで、"syn reset"または "syn ack"ビットをセットした応答を返す状態で、すなわちそれは、前 に確立されたセッションには含まれていないパケットが許可されてい ることを意味するが、NMAP を実行する）） 1.3.5 データベースが内部ネットワーク・ゾーンにあり、DMZ からは 分離されているかを調べる。 1.3.6 外部へ送信されるトラフィックがカード会員環境にとって必要 でかつ文書化されているものに制限されているかを調べる。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 7 PCI セキュリティ監査手順 安全なネットワークの構築・維持 要 件 1.3.7 ルーター設定ファイルの安 全保護と同期（例：実行中の設定 ファイル（ルーターの通常実行に 使用）、起動時設定ファイル（マシ ンのリブート時に使用）が、同じ安 全な設定がされている必要があ る）。 1.3.8 許可されたものを除くすべ てのトラフィックの拒否。 1.3.9 無線ネットワークと決済カー ド環境との間の境界ファイアウォー ルの導入と、無線環境からのトラフ ィックを（それらが業務目的にとっ て必要な場合）拒否または制御す るためのファイアウォールの設定。 1.3.10 インターネットに直接接続 するモバイル・コンピュータや従業 員所有のコンピュータで、社内ネ ットワークへのアクセスに使用され るもの（例：、従業員が使用するラ ップトップ）へのパーソナル・ファイ アウォール・ソフトウェアの導入。 1.4 外部ネットワークと、カード会員 情報を格納するシステム・コンポーネ ント（例：、データベース）との間で、 直接自由にアクセスできることを禁止 する。 テスト手順 1.3.7 ルーター設定ファイルが安全でかつファイル間の同期がとれ ている（例：実行中の設定ファイル（ルーターの通常実行に使用）、起 動設定ファイル（マシンのリブート時に使用）が、同じ安全な設定にな っている）かを調べる。 対 応 未対応 目標期日／コメント 1.3.8 1.2.1 項でカバーされていない他のすべてのトラフィックが個別 に拒否されているかを調べる。 1.3.9 無線ネットワークとカード会員情報を格納するシステムとの間 に境界ファイアウォールが導入され、かつそれらのファイアウォール が無線環境からカード会員情報を格納するシステムへのトラフィック を拒否または制御（それらが業務目的にとって必要な場合）するかを 調べる。 1.3.10 インターネットに直接接続するモバイル・コンピュータや従業 員所有コンピュータで、組織のネットワークへのアクセスに使用される もの（例：従業員が使用するラップトップ）にパーソナル・ファイアウォ ール・ソフトウェアが導入され、正常に動作し、かつ組織によって特定 の標準に従って設定され、その設定が従業員によって変更不可能で あるかを確認する。 1.4 外部の公衆ネットワークと、カード会員情報を格納するコンポーネ ントとの間の直接アクセスを禁止するために、特に DMZ と内部ネットワ ークとの間に実装されたファイアウォール／ルーターの設定について、 次のことを実行する。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 8 PCI セキュリティ監査手順 安全なネットワークの構築・維持 要 件 テスト手順 対 応 未対応 目標期日／コメント 1.4.1 ファイアウォール／ルーターの設定を検証し、すべてのインタ 1.4.1 すべてのインターネット・トラ ーネット・トラフィックの直接経路がないかを調べる。 フィックの直接経路を禁止するた めに、すべてのトラフィックをフィル タリングおよび検査する DMZ の 実装。 1.4.2 ファイアウォール／ルーターの設定を検証し、カード会員アプ 1.4.2 決済アプリケーションから リケーションからの内部から発信するトラフィックが DMZ 内の IP アド DMZ 内の IP アドレスに対する内 レスのみをアクセスできるようになっているかを調べる。 部 から発 信す るト ラフィックの 制 限。 1.5 内部アドレスのインターネット上 1.5 上記のファイアウォール／ルーター・コンポーネントの場合、NAT での変換、漏洩を防止するために、 またはその他の RFC 1918 アドレス空間を実装するための技術を利用 インターネット・プロトコル（IP）マスカ して、内部ネットワークからインターネットへの IP アドレスのブロードキャ レードを実装する。ポート・アドレス変 スト（同報）が制限されているかを確認する（IP マスカレード）。 換（PAT）やネットワーク・アドレス変 換（NAT）など、RFC 1918 アドレス 空間を実装するための技術を使用 する。 要件 2：システムまたはソフトウェアの出荷時の初期設定値（セキュリティに関する設定値）をそのまま利用しないこと ハッカー（社外および社内）は、しばしばベンダー出荷時のデフォルト・パスワードやその他ベンダーのデフォルト設定を使用して、システムのセキュリティを脅かす。これら のパスワードや設定は、ハッカーの間でよく知られており、公開情報を通じて容易に見つけ出すことができる。 2.1 システムをネットワーク上に導入 2.1 システム・コンポーネントのサンプルを使用し、デフォルトのベンダ する前にベンダー出荷時のデフォル ー出荷時のアカウントとパスワードを使用したデバイスへのログオンを試 ト値を必ず変更する（例：パスワード、 み（システム・アドミニストレータの助けを借りる）、デフォルトのアカウント SNMP コミュニティ文字列の変更、 とパスワードが変更されていることを確認する（ベンダーのマニュアルと インターネット上の情報源を使って、ベンダー出荷時のアカウント／パス 不必要なアカウントの削除）。 ワードを見つける）。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 9 PCI セキュリティ監査手順 安全なネットワークの構築・維持 要 件 2.1.1 無線環境の場合、無線 ベンダーのデフォルト値を変更 する。これには、WEP キー、デ フォルトの SSID、パスワード、 SNMP コミュニティ文字列を変 更したり、SSID ブロードキャスト を無効にするなどの作業が含ま れる。また、WPA 対応の場合、 暗号化と認証のための Wi-Fi 保護アクセス（WPA）技術を有 効にする。 2.2 すべてのシステム・コンポー ネントについて、設定標準を作成 する。この標準では、既知のすべ てのセキュリティ脆弱性と業界の ベスト・プラクティスを必ず取り上 げる。 2.2.1 各サーバーには主要機 能を 1 つだけ実装する（例：、 Web サーバー、データベース・ サーバー、DNS は、別々のサ ーバーに実装されるべきであ る）。 テスト手順 2.1.1 無線環境に関するベンダーのデフォルト設定について、次のこと を確認する。 ● WEP キーがインストール時にデフォルトから変更されており、キー を知っている人が退社したか、異動するたびに変更されている。 ● デフォルトの SSID が変更されている。 ● SSID のブロードキャストが無効になっている。 ● アクセス・ポイント上のデフォルトの SNMP コミュニティ文字列が変 更されている。 ● アクセス・ポイント上のデフォルトのパスワードが変更されている。 ● 無線システムが WPA 対応の場合、WPA 技術が有効になってい る。 ● 他のセキュリティ関連無線ベンダーのデフォルトがある場合、その 値。 2.2.a 無線アクセス・ポイントを含む、ネットワークのコンポーネントと重要 なサーバーに関する組織のシステム設定標準を調べて、以下の各項目が 標準に含まれているかを確認する。 2.2.b また、新しいシステムを設定する際は、以下の各項目がプロセスに 含まれているかを調べる。 対 応 未対応 目標期日／コメント 2.2.1 サーバーごとに 1 つの主要機能だけが実装されている。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 10 PCI セキュリティ監査手順 安全なネットワークの構築・維持 要 件 2.2.2 不必要で、信頼できない サービスやプロトコル（装置の 指定された機能を実行するの に直接必要ではないサービス やプロトコル）は、すべて無効に する。 2.2.3 誤用を防止するように、 システムのセキュリティ・パラメー タを設定する。 2.2.4 スクリプト、ドライバ、フィ ーチャー、サブシステム、ファイ ル・システムなど、不必要な機 能（例：、不必要な Web サーバ ー）をすべて取り除く。 テスト手順 2.2.2 有効になっているシステム・サービス、デーモン、プロトコルをサ ンプル（サンプルの番号または記述、もしくはその両方を記入）から入手 し、点検する。不必要なまたは安全ではないサービスまたはプロトコル が有効になっていないこと、およびサービスの適切な使用に関連して、 潜在的に危険なものの必要な理由が明確になっており、また文書化さ れていることを確認する（例：FTP が使用されていない、もしくは SSH ま たは他の技術によって暗号化されている）。 2.2.3.a システム・アドミニストレータまたはセキュリティ・マネージャ、もし くはその両方に対して、オペレーティング・システム、データベース・サ ーバー、Web サーバー、無線システムに関する共通のセキュリティ・パ ラメータ設定を認識しているかを質問する。 2.2.3.b 共通のセキュリティ・パラメータ設定がシステム設定標準に含ま れているかを確認する。 2.2.3.c すべてのシステム・コンポーネントのサンプル、データベースや 重要なサーバー（無線を含む）のサンプル（サンプルの番号または記 述、もしくはその両方を記入）を選択し、共通のセキュリティ・パラメータ が適切に設定されているかを確認する。 2.2.4 システム・ファイルを入手および検査して、不必要な機能（例：ドラ イバ、機能、サブシステム、ファイル・システム、その他）がすべて取り除 かれているかを調べる。また、有効になっている機能が文書化されてい るか、安全な設定をサポートし、サンプル・マシン上に存在する唯一の ものであるかを確認する。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 対 応 未対応 目標期日／コメント 11 PCI セキュリティ監査手順 安全なネットワークの構築・維持 要 件 テスト手順 2.3 非コンソール管理アクセスは 2.3 システム・コンポーネントのサンプル（サンプルの番号または記述、も すべて暗号化する。Web ベース しくはその両方を記入）から、次のようにして、非コンソールのアドミニストレ の管理やその他の非コンソール管 ータ・アクセスが暗号化されているかを確認する。 理 ア ク セ ス に は SSH 、 VPN 、 ● 各サンプル・システム上のアドミニストレータ・ログを見て、アドミニスト SSL/TLS な ど の 技 術 を 使 用 す レータのパスワードが要求される前に SSH（または他の暗号化手段） る。 が起動されているかを調べる。 ● サンプル・システム上のサービスおよびパラメータ・ファイルをレビュー して、Telnet および他のリモート・ログイン・コンポーネントが内部では 利用不可能になっているかを確認する。 ● 無線管理インターフェースへのアドミニストレータ・アクセスが SSL/TLS によって暗号化されているかを確認する。すなわち、アドミ ニストレータが無線管理インターフェースにリモートで接続できない （無線環境の全管理がコンソールからのみ行える）ことを確認する。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 対 応 未対応 目標期日／コメント 12 PCI セキュリティ監査手順 カード会員情報の保護 要 件 テスト手順 対 応 未対応 目標期日／コメント 要件 3：保存されたデータを安全に保護すること 暗号化は最後の情報保護手段で、たとえ誰かが他のすべての保護メカニズムを破りデータにアクセスしても、暗号を破らなければデータを読み取ることはできない。防御 に関する詳しい原則を次に示す。 3.1 格納されるカード会員情報を 3.1 データの保存と廃棄に関する会社のポリシーと手順を入手し、ポリシ 最小限に抑える。データの保存と ーと手順に次の項目が含まれているかを確認する。 廃棄に関するポリシーを作成す ● カード会員情報の保存に関する具体的要件（例：カード会員情報は、 る。データ保存ポリシーの記述に X という期間、Y という業務上の理由で保存する必要がある）を含む、 従って格納される情報量と保存期 データ保存に関する法律上、規制上、業務上の要件。 間を業務上、法律上、規制上必要 ● 法律上、規制上、業務上の理由で不必要になった時点でデータを廃 な範囲に制限する。 棄すること。 ● データベース・サーバー、メインフレーム、サーバー間のデータ転送 に使用される転送ディレクトリとバルク・データ・コピー・ディレクトリ、サ ーバー転送間のデータ正規化に使用されるディレクトリを含む、カー ド会員情報の全格納範囲。 ● 業務上の保存要件を超えて格納されているカード会員情報を少なく とも四半期ごとに削除するためのプログラマティック（自動的）プロセ ス。すなわち、格納されたカード会員情報が業務上の保存要件を超 えていないかを少なくとも四半期ごとに確認するための監査の実施。 3.2 オーソリゼーション後に機密 3.2 機密認証データを受け取りおよび消去する場合、データが復元不可 認証データを格納しない（データ 能であることを判断するために、データの消去方法を入手およびレビュー が 暗 号 化 さ れ て い た 場 合 も 同 する。以下のように各機密データについて、次の手順を実行する。 様）。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 13 PCI セキュリティ監査手順 カード会員情報の保護 要 件 3.2.1 磁気ストライプのすべて の情報（カードの裏面、チップ 内、その他）は格納しない。 3.2.2 カード認証コード（カード の前面もしくは裏面に印刷され た 3 桁または 4 桁の値（例：、 CVV2 、 CVC2 、 CAV2 デ ー タ））を格納しない。 3.2.3 PIN 検証値（PVV）を格 納しない。 テスト手順 3.2.1 選択したサンプルについて次の項目を調べて、カード裏面の磁 気ストライプのトラックの内容（CVV データ）がいかなる場合も格納され ないことを確認する。 ● 受信トランザクション・データ ● トランザクション・ログ ● 履歴ファイル ● 複数のデータベース・スキーマ 3.2.2 選択したサンプルについて次の項目を調べて、署名パネルに印 刷された 3 桁または 4 桁のカード確認コード（CVV2/CVC2/CAV2 デー タ）がいかなる場合も格納されないことを確認する。 ● 受信トランザクション・データ ● トランザクション・ログ ● 履歴ファイル ● 複数のデータベース・スキーマ 3.2.3 選択したサンプルについて次の項目を調べて、PIN 検証値 （PVV データ）がいかなる場合も格納されないことを確認する。 ● 受信トランザクション・データ ● トランザクション・ログ ● 履歴ファイル ● 複数のデータベース・スキーマ © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 対 応 未対応 目標期日／コメント 14 PCI セキュリティ監査手順 カード会員情報の保護 要 件 3.3 カード番号は、全体を表示さ せない（例：最大でも最初の 6 桁と 最後の 4 桁を表示）。 従業員などがカード番号全体を見 る特別な必要がある場合、この原 則は適用しなくてもよい。 テスト手順 3.3 書面のポリシーを入手およびレビューし、クレジット・カード・データの オンライン表示をレビューして、クレジット・カード番号全体を見る必要が特 にある場合を除き、カード会員情報を表示する際にカード番号全体が表 示されていないかを確認する。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 対 応 未対応 目標期日／コメント 15 PCI セキュリティ監査手順 カード会員情報の保護 要 件 3.4 カード会員情報は、次のいず れかの手段を使用して、それが格 納された場所で読み取り不可能な 状態にする（携帯メディア、ログ、 無線ネットワークから受信、もしく は無線ネットワーク経由で格納さ れるデータを含む）。 ● SHA-1 などの一方向ハッシュ （ハッシュ・インデックス）。 ● トランケーション（文字の一部 を非表示にする） ● インデックス・トークンや PAD。PAD は安全に格納 ● 強 力 な 暗 号 。 Triple-DES 128 ビットまたは AES 256 ビ ットと鍵管理プロセスおよび 手順の組み合わせなど テスト手順 3.4.a 格納データの保護に使用される暗号システムに関するドキュメンテ ーション（ベンダー、暗号システムのタイプ、暗号化アルゴリズムを含む）を 入手する。データが次のいずれかのアルゴリズムを使用して読み取り不可 能な状態になっていることを確認する。 ● SHA-1 などの一方向ハッシュ（ハッシュ・インデックス） ● トランケーションまたはマスキング ● インデックス・トークンや PAD。PAD は安全に格納 ● 強力な暗号化。Triple-DES 128 ビットまたは AES 256 ビットとキー 管理プロセスおよび手順の組み合わせなど 対 応 未対応 目標期日／コメント 3.4.b データベース・マシンのサンプル内の各データベース・サーバーに ある複数のテーブルを調べて、データが暗号化されている（すなわち、平 文で格納されていない）ことを確認する。 3.4.c リムーバブル・メディア（例：バックアップ・テープ）のサンプルを調べ て、カード会員情報が暗号化されていることを確認する。 3.4.d 監査ログのサンプルを調べて、カード会員情報がログから消去また 少なくともカードの番号は読取不 は削除されていることを確認する。 可能な状態にする必要がある。 3.4.e 無線ネットワークから受信したカード会員情報が格納時に暗号化さ れていることを確認する。 3.5 暗号鍵を、漏洩と不正使用か 3.5 次のことを実行して、暗号化鍵を漏洩や不正使用から保護するため ら保護する。 のプロセスを確認する。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 16 PCI セキュリティ監査手順 カード会員情報の保護 要 件 テスト手順 3.5.1 鍵へのアクセスを、必要 3.5.1 ユーザー・アクセス・リストを調べて、暗号鍵へのアクセスがごく少 最小限の管理者に制限する。 数の管理者に制限されていることを確認する。 3.5.2 システム設定ファイルをレビューして、暗号鍵が暗号化された状 3.5.2 鍵は安全に保管し、その 態で保管され、かつ鍵暗号化鍵がデータ暗号化鍵と分けて保管されて 場所と方式を最小限にとどめ いることを確認する。 る。 3.6 すべての鍵管理プロセスおよ 3.6.a 鍵管理手順の存在を確認する。 び手順をすべて文書化し実施す 3.6.b サービス・プロバイダのみ。サービス・プロバイダが、カード会員情 報の伝送に関わる鍵を顧客と共有している場合、顧客の暗号化鍵（顧客と る。 サービス・プロバイダとの間のデータ伝送に使用される）を安全に格納およ び変更する方法の指針を含むドキュメンテーションをサービス・プロバイダ が顧客に提供していることを確認する。 鍵管理手順を調べ、手順が次の項目を要求していることを確認する。 3.6.1 強力な鍵の生成。 3.6.1 強力な鍵の生成。 3.6.2 安全な鍵の配布。 3.6.2 安全な鍵の配布。 3.6.3 安全な鍵の保管。 3.6.3 安全な鍵の保管。 3.6.4 定期的な鍵の変更。 3.6.4 定期的な鍵の変更。 3.6.5 古い鍵の破壊。 3.6.5 古い鍵の破壊。 3.6.6 鍵の分割管理と二重管理（鍵全体を再構築するには、2～3 人を 3.6.6 鍵の分割管理と二重管 必要とし、各自が鍵の一部のみを知っている）。 理（鍵全体を再構築するには、 2～3 人を必要とし、各自が鍵の 一部のみを知っている）。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 対 応 未対応 目標期日／コメント 17 PCI セキュリティ監査手順 カード会員情報の保護 要 件 3.6.7 鍵の不正置換の防止。 3.6.8 鍵の危殆が発覚、もしく はそのような可能性のある鍵の 交換。 3.6.9 古いまたは無効になった 鍵の廃棄（おもに RSA キー）。 3.6.10 鍵 管 理 者 が 自 身 の 責 務を理解し、それを受諾したこ とを示す書式への署名の要求。 テスト手順 3.6.7 鍵の不正置換の防止。 3.6.8 鍵の危殆が発覚、もしくはそのような可能性のある鍵の交換。 対 応 未対応 目標期日／コメント 3.6.9 古いまたは無効になった鍵の廃棄（おもに RSA キー）。 3.6.10 鍵管理者が自身の責務を理解し、それを受諾したことを示す書 式への署名。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 18 PCI セキュリティ監査手順 カード会員情報の保護 要 件 テスト手順 対 応 未対応 要件 4：公衆ネットワーク上でカード会員情報およびセンシティブ情報を送信する場合、暗号化すること センシティブ情報をインターネットで伝送する場合、ハッカーにより容易に傍受および改ざんされることがあるため暗号化しなければならない。 4.1 公衆ネットワークを通じて機 4.1.a 次のことを実行して、カード会員情報を、インターネットを通じて送 密のカード会員情報を伝送する場 信または受信する際に暗号化（例：、SSL）が使用されていることを確認す 合 、 セ キ ュ ア ・ ソ ケ ッ ト ・ レ イ ヤ ー る。 （SSL）、ポイントツーポイント・トン ● データ伝送時に少なくとも 128 ビットの暗号化が使用されていることを ネリング・プロトコル（PPTP）、イン 確認する。 ターネット・プロトコル・セキュリティ ● SSL 実装の場合、ブラウザのユニフォーム・リソース・ロケータ（URL） (IPSEC)などの強力な暗号化技 に HTTPS が表示されること、および HTTPS が URL に表示されて 術（最小 128 ビット）を使用する。 いないときは、カード会員情報が要求されないことを確認する。 ● 受信時のトランザクションのサンプルを選択し、生じたトランザクション を調べて、カード会員情報が伝送時に暗号化されることを確認する。 ● 信用される SSL キー／証明書のみを受け付けることを確認する。 4.1.b 使用中の暗号化方法について、適切な暗号化強度が実装されて いることを確認する。たとえば、 ● 3DES - 128 ビット ● AES - 256 ビット ● RSA - 1024 ビット ● 他の暗号化方法に関するベンダーの推奨事項／ベスト・プラクティス をチェックする。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 目標期日／コメント 19 PCI セキュリティ監査手順 カード会員情報の保護 要 件 テスト手順 4.1.1 カード会員情報を伝送するか、カード会員環境と接続された無 4.1.1 無線ネットワークを通じて 線ネットワークについて、次の項目を確認する。 カード会員情報を伝送する場 合、可能であれば Wi-Fi 保護 ● 無線伝送ネットワークについて、VPN、128 ビットの SSL/TLS、 アクセス（WPA）技術を使用し、 128 ビットの Wired Equivalency Protocol（WEP）、WPA など、 そうでない場合は VPN または 適切な暗号化方式が使用されていること。 SSL128 ビットを使用してデー ● WEP が使用されている場合、共有 WEP キーを少なくとも四半期 タを暗号化する。無線 LAN 上 ごとまたは主要担当者の変更時にローテーションするためのプロセ での信頼性の維持、安全なアク スが実施されていることを確認する。 セスを確保するために、WEP ● WEP が使用されている場合、データを保護するために、WEP 以 だけには頼らないこと。上記の 外の方式も実施されていることを確認する。 いずれかの手段を 128 ビットの ● 自動化された鍵・ローテーション・プロセスの場合、鍵が 10～30 分 WEP と組み合わせて使用し、 ごとに変更されることを確認する。 共有 WEP キーは四半期ごとま たは人事異動があったときに変 更する。 4.2 カード会員情報は暗号化され 4.2.a 電子メール暗号化ソフトウェアが従業員のパーソナル・コンピュータ ていない状態で、電子メールを通 上に存在しているかを調べる。 4.2.b カード会員情報を暗号化されていない電子メールを通じて送信しな じて送信しない。 いように規定したポリシーが存在することを確認する。 4.2.c カード会員情報を含んだ電子メールには、電子メール暗号化ソフト ウェアの使用が要求されているかを 3～5 人の従業員に質問して確認す る。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 対 応 未対応 目標期日／コメント 20 PCI セキュリティ監査手順 脆弱性を管理するプログラムの整備 要 件 テスト手順 対 応 未対応 目標期日／コメント 要件 5：アンチウィルス・ソフトウェアを利用し、定期的にソフトを更新すること 多くの場合、脆弱性や悪意のあるウィルスは、従業員の電子メール操作を通じてネットワークに侵入する。システムを悪意のあるソフトウェアから保護するために、すべての 電子メール・システムとデスクトップでアンチウィルス・ソフトウェアを利用しなければならない。 5.1 ウィルスによる影響を受けや 5.1 システム・コンポーネントのサンプル（サンプルの番号または記述、も すいすべてのシステム（例：PC、 しくはその両方を記入）においてアンチウィルス・ソフトウェアが導入されて サーバー）にアンチウィルス・メカ いるかを確認する。 ニズムを導入する。 5.2 すべてのアンチウィルス・メカ 5.2 アンチウィルス・ソフトウェアが（現在日を挿入）現時点で最新版であ ニズムが最新版で、正常に稼動し り、正常に動作しており、監査ログを生成できることを確認するには、次の ており、監査ログを生成できること 項目を実行する。 を確認する。 ● アンチウィルス・ソフトウェアと定義の更新を要求するポリシーを入手 およびレビューする。 ● ソフトウェアのマスターをインストールすることで自動更新と定期的スキ ャンが有効になっており、上の 5.1 で調べたサーバーで、これらの機 能が有効になっていることを確認する。 ● ログ生成が有効になっており、ログが会社の保存ポリシーに従って保 存されていることを確認する。 要件 6：安全性の高いシステムとアプリケーションを開発し、保守すること 悪意を持った人々は、セキュリティの脆弱性を利用して、システムへの特権アクセスを手にいれる。このような脆弱性の多くは、ベンダーのセキュリティ・パッチを通じて修正 される。したがって、すべてのシステムは最新のソフトウェア・パッチを適用することにより、従業員、外部ハッカー、ウィルスによる不正使用から保護される必要がある。自社 開発アプリケーションの場合、標準の開発プロセスと安全なコーディング・テクニックを使用することにより多くの脆弱性を回避できる。 6.1 すべてのシステム・コンポー 6.1 システム・コンポーネントとソフトウェアサンプル（サンプルの番号また ネントとソフトウェアに最新のベン は記述を記入）を使用して、各システムに導入されたセキュリティ・パッチ ダー供給セキュリティ・パッチが適 のリストと、最新ベンダー・セキュリティ・パッチのリストを比較して、現行の ベンダー・セキュリティ・パッチが導入されていることを確認する。 用されていることを確認する。 6.1.1 セキュリティ・パッチの導入に関するポリシーを調べて、関連する 6.1.1 関連するセキュリティ・パ すべての新しいセキュリティ・パッチを 30 日以内に導入することが要求 ッチをリリース後 1 か月以内に されているかを確認する。 導入する。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 21 PCI セキュリティ監査手順 脆弱性を管理するプログラムの整備 要 件 6.2 新しく見つかったセキュリティ 脆弱性を識別するためのプロセス （例：インターフェース上で無料で 利用可能な警告サービスに加入 する）を確立する。新しい脆弱性 の問題に対処するために標準を 更新する。 6.3 ソフトウェア・アプリケーション は、業界のベスト・プラクティスに 基づいて開発し、ソフトウェアの全 開発ライフ・サイクルを通じて情報 セキュリティを徹底する。情報セキ ュリティには次の項目が含まれる。 6.3.1 すべてのセキュリティ・パ ッチ、ならびにシステムとソフト ウェアの設定変更は、展開前に テストする。 6.3.2 開発／テスト環境と本番 環境は分離する。 6.3.3 開発／テスト環境と本番 環境との間で、役割を分離す る。 6.3.4 実データ（実際のカード 番号など）を、テスト／開発では 使用しない。 6.3.5 本番システムが稼動する 前にテスト・データおよびアカウ ントを取り除く。 テスト手順 6.2 セキュリティ脆弱性情報を得るために外部情報源の使用と、新しい脆 弱性問題が見つかったときの要件 2 でレビューされたシステム設定標準の 更新が、新しいセキュリティ脆弱性を識別するために実施されているプロ セスに含まれているかをプロセスの担当者に質問する。 対 応 未対応 目標期日／コメント 6.3 書面のソフトウェア開発プロセスを入手し、それが業界標準に基づい ており、全開発ライフ・サイクルを通じてのセキュリティが含まれていること を確認する。ソフトウェア開発プロセス記述のレビュー、ソフトウェア開発者 への質問から、関連データ（ネットワーク構成ドキュメンテーション、本番お よびテスト・データ、その他）のレビューから、次の項目を確認する。 6.3.1 すべての変更（パッチを含む）が本番システムへの展開前にテス トされている。 6.3.2 テスト／開発環境は本番環境から分離され、分離を実現するた めにアクセス制御が実施されている。 6.3.3 開発／テスト環境の担当者と本番環境の担当者の責務が分離さ れている。 6.3.4 テストおよび開発環境で使用されるデータを調べ、本番データ （実際のカード番号）がテストおよび開発目的で使用されていないこと、 または使用前に消去されていることを確認する。 6.3.5 テスト・データおよびアカウントは、本番システムが運用を開始す る前に取り除く。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 22 PCI セキュリティ監査手順 脆弱性を管理するプログラムの整備 要 件 6.3.6 個別開発アプリケーショ ンのアカウント、ユーザー名、パ スワードを、アプリケーションが 実稼動するか、顧客にリリースさ れる前に取り除く。 6.3.7 プログラムコードを検証 し、本番または顧客へのリリース 前にコーディングの脆弱性がな いことを確認する。 6.4 システムおよびソフトウェアの 設定を変更する場合、変更管理 手順に従う。手順には次の項目が 含まれている必要がある。 6.4.1 影響を受けるドキュメンテ ーションの見極め。 6.4.2 適切な担 当者によ る承 認。 6.4.3 運用機能を検証するた めのテスト。 6.4.4 回復手順。 テスト手順 6.3.6 カスタム・アプリケーションのアカウント、ユーザー名、パスワード は、システムが実稼動するか、顧客にリリースされる前に取り除く。 対 応 未対応 目標期日／コメント 6.3.7.a 書面のポリシーを入手およびレビューし、プログラムコード・レビ ューが必須で、それをコードの作成者以外の人が行うことが記述されて いるかを確認する。 6.3.7.b 新しいプログラムコードおよびプログラムコード変更後にコー ド・レビューが行われることを確認する。 6.4 セキュリティ・パッチとソフトウェア変更に関する会社の変更管理手順 を入手し、以下の項目 6.4.1～6.4.4 が必須になっていることを確認する。 システム・コンポーネントのサンプルを選択する。各システム・コンポーネン トについて最新の 3 つの変更／セキュリティ・パッチを見つけ、それらの変 更をもとの変更管理ドキュメンテーションと照らし追跡する。次のようにし て、変更管理プロセスが実装されていることを確認する。 6.4.1.a 各サンプル変更に関する変更管理ドキュメンテーションに顧客 への影響に関する記述が含まれていることを確認する。 6.4.2 それぞれのサンプル変更について、適切な関係者による承認が 存在することを確認する。 6.4.3 各サンプル変更について、運用機能を検証するためのテストが 実行されたことを確認する。 6.4.4 各サンプル変更について取り消し手順が用意されていることを確 認する。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 23 PCI セキュリティ監査手順 脆弱性を管理するプログラムの整備 要 件 6.5 Web ソフトウェアおよびアプリケーショ ンは、『Open Web Application Security Project（オープン Web アプリケーション・ セキュリティ・プロジェクト）』ガイドラインな どの安全なコーディング・ガイドラインに基 づいて開発する。カスタム・アプリケーショ ン・コードはコーディングの脆弱性がない か を レ ビ ュ ー す る 。 詳 し く は www.owasp.org の 「 The Ten Most Critical Web Application Security Vulnerabilities（最も重要な 10 項目の Web アプリケーション・セキュリティ脆弱 性）」を参照すること。次に示すソフトウェ ア開発プロセスにおける共通のコーディン グ脆弱性の防止に努める。 6.5.1 入力データの未検証。 6.5.2 アクセス制御の不徹底（例：ユー ザーID の悪意のある使用）。 6.5.3 認証およびセッション管理の不 徹底（アカウント証明書とセッション・クッ キーの使用）。 6.5.4 クロスサイトスクリプト（XSS）攻 撃。 6.5.5 バッファ・オーバーフロー。 6.5.6 入力不正（例：SQL インジェクシ ョン）。 6.5.7 不適切なエラー処理。 6.5.8 安全ではない格納。 テスト手順 6.5.a 任意の Web ベース・アプリケーションについて、ソフトウェア 開発プロセスを入手および調査する。プロセスが開発者に対して 安全なコーディング・テクニックのトレーニングを要求しており、か つ OWASP などの指針に基づいていることを確認する。 6.5.b 任意の Web ベース・アプリケーションについて、Web 開発 者のサンプル（サンプル・サイズを記入）に対して質問し、安全なコ ーディング・テクニックを認識していることを確認する。すなわち、 定期的な外部コードのレビューまたはアプリケーションの侵入テス トが OWASP 指針に基づいて実行され、コーディングに関する脆 弱性がすべて修正および再評価されているかを調べる。 任意の Web ベース・アプリケーションについて、次の項目に対して 脆弱ではないことを確認するためのプロセスが実施されているかを 調べる。 対 応 未対応 目標期日／コメント 6.5.1 入力データの未検証。 6.5.2 ユーザーID の悪用。 6.5.3 アカウント証明書とセッション・クッキーの悪用。 6.5.4 クロスサイトスクリプト。 6.5.5 妥当性検査されていない入力やその他の原因によるバッ ファ・オーバーフロー。 6.5.6 SQL インジェクションやその他の入力不正。 6.5.7 エラー処理の不正。 6.5.8 安全ではない格納。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 24 PCI セキュリティ監査手順 脆弱性を管理するプログラムの整備 要 件 6.5.9 サービスの拒否。 6.5.10 信頼できない設定管理。 テスト手順 対 応 未対応 目標期日／コメント 6.5.9 サービスの拒否。 6.5.10 信頼できない設定管理。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 25 PCI セキュリティ監査手順 強固なアクセス制御手法の導入 要 件 テスト手順 対 応 要件 7：データアクセスを業務上の必要範囲内に制限すること 重要なデータは許可された方法でのみアクセスできるようにする。 7.1 コンピューティング・リソースと 7.1 データ管理に関する書面のポリシーを入手し、次の項目が含まれて カード会員情報へのアクセスを業 いることを確認する。 務上必要な人に限定する。 ● 特権ユーザーID に関するアクセス権限は、職務の実行に必要な最 小限の特権に制限されている。 ● 個人への特権の付与は、職種と職能に基づいている。 ● 管理権限者により署名され、必要な特権を特定する許可フォームが 必須であること。 ● 自動化されたアクセス管理システム。 7.2 複数のユーザーを持つシス 7.2 システム設定とベンダードキュメンテーションを調べて、アクセス管理 テムについて、ユーザーの業務権 システムが実施され、かつ次の項目を含むことを確認する。 限に基づいてアクセスを制限し、 ● すべてのシステム・コンポーネントのカバレージ。 個別に許可されないかぎり「すべ ● 職種と職能に基づく個人への特権の付与。 てを拒否」に設定されたメカニズム ● デフォルトで「すべてを拒否」の設定（一部のアクセス管理システム を確立する。 は、デフォルトで「すべてを許可」に設定されており、個別に拒否する ためのルールを記述しないかぎり、または記述するまでは、アクセスが 許可されてしまう）。 要件 8：コンピュータにアクセスする際、利用者毎に識別 ID を割り当てること 重要なデータやシステムに対する操作が既知の許可を受けたユーザーのみによって実行され、その操作を追跡できるようにする。 8.1 すべてのユーザーについて、 8.1 システム・コンポーネントのサンプル（サンプルの番号または記述、も システム・コンポーネントまたはカ しくはその両方を記入）について、ユーザーID リストをレビューし、すべて ード会員データへのアクセスを許 のユーザーがシステム・コンポーネントまたはカード会員情報にアクセスす 可する前に一意なユーザー名で るために一意なユーザー名を持っていることを確認する。 識別する。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 未対応 目標期日／コメント 26 PCI セキュリティ監査手順 強固なアクセス制御手法の導入 要 件 8.2 すべてのユーザーを認証す る際は、一意な識別に加え以下に 示す手段の少なくとも 1 つを実施 する。 ● パスワード ● トークン・デバイス（例： SecureID 、 証 明 書 、 ま た は 公開鍵） ● バイオメトリックス（生体認証） 8.3 従業員、アドミニストレータ、 第三者によるネットワークへのリモ ート・アクセスのために二つの認証 手段の組み合わせを実装する。 RADIUS または TACACS とトー クン、VPN と個別証明書などの技 術の組み合わせを使用する。 8.4 すべてのシステム・コンポー ネント上での伝送と格納の処理に おいて、あらゆるパスワードを暗号 化する。 テスト手順 8.2 ユーザーがカード会員環境にアクセスする際に一意な ID および別の 認証項目（例：パスワード）によって認証されていることを確認するために、 次の項目を実行する。 ● 使用されている認証方法を記述したドキュメンテーションを入手する。 ● 使用されている各認証方法について、それぞれのシステム・コンポー ネント・タイプに対して 1 回ずつ、認証を観察して、ドキュメンテーショ ンに記述された認証方法に従って実行されているかを確認する。 対 応 未対応 目標期日／コメント 8.3 すべてのリモート・ネットワーク・アクセスについて二つの認証手段の 組み合わせが使用されていることを確認するために、従業員（例：アドミニ ストレータ）がネットワークにリモートから接続するようすを観察し、パスワー ドおよび別の認証手段（スマート・カード、トークン PIN など）の両方が必 須になっていることを確認する。 8.4.a カード会員環境で選択されたシステム・コンポーネントについて、パ スワード・ファイルを調べて、パスワードが読み取り不可能になっているか を確認する。すべてのシステム・コンポーネントに関するパスワード・ファイ ルが含まれる。 8.4.b サービス・プロバイダのみ。パスワード・ファイルを調べて、顧客のパ スワードが暗号化されているかを確認する。 8.5 非消費者ユーザーとアドミニ 8.5 次の項目を実行することにより、手順のレビューとディスカッションを通 ストレータに対して、すべてのシス じて、ユーザー認証とパスワード管理のための手順が存在することを確認 テム・コンポーネント上において適 する。 切なユーザー認証とパスワード管 理を徹底する。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 27 PCI セキュリティ監査手順 強固なアクセス制御手法の導入 要 件 8.5.1 ユーザーID、証明書、そ の他識別オブジェクトの追加、 削除、変更を管理する。 8.5.2 パスワードをリセットする 前にユーザー識別を検証す る。 8.5.3 初回パスワードはユーザ ーごとに異なる値に設定し、初 回使用後、直ちに変更するよう にする。 8.5.4 離職したユーザーのアク セスは直ちに取り消す。 8.5.5 少なくとも 90 日ごとに休 眠状態のユーザー・アカウント を取り除く。 テスト手順 8.5.1.a ユーザーID のサンプル（番号を記入）を選択する。これには、 サンプル・システム・コンポーネントのアドミニストレータと一般ユーザー の両方が含まれる。各ユーザーが会社のポリシーに従って認証されるこ とを確認するために、次の項目を実行する。 ● それぞれの ID に関する認証フォームを入手する。 ● 認証フォームからシステムへの情報を追跡して、ID が認証フォー ムに従って実装されていること（例：指定された特権を持っている、 すべての署名が入手されているなど）を確認する。 8.5.1.b アドミニストレータのみが無線ネットワークの管理コンソールに アクセスできるようになっているかを確認する。 8.5.2 パスワード手順を調べ、セキュリティ担当者を観察して、ユーザ ーが電話、電子メール、Web、またはその他の直接対面しない方法で パスワードのリセットを要求した場合、パスワードをリセットする前にユー ザーの識別が検証されることを確認する。 8.5.3 パスワード手順を調べ、セキュリティ担当者を観察して、新規ユ ーザーの初回パスワードがユーザーごとに一意な値に設定され、初回 使用後に変更されていることを確認する。 対 応 未対応 目標期日／コメント 8.5.4 過去 6 か月に離職した従業員のサンプル（番号を記入）を選択 し、（現在日付を記入）現在のユーザー・アクセス・リストをレビューして、 ID が非アクティブになっているか、または削除されていることを確認す る。 8.5.5 上で選択したユーザーID のサンプルから、90 日を超える非アク ティブなアカウントがないことを確認する。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 28 PCI セキュリティ監査手順 強固なアクセス制御手法の導入 要 件 8.5.6 ベンダーがリモート保守 に使用するアカウントは、必要 な期間のみ有効にする。 8.5.7 カード会員情報にアクセ スするすべてのユーザーにパス ワード利用手順とポリシーを配 布する。 8.5.8 グループ、共有、または 汎用のアカウント／パスワードを 許可しないこと。 テスト手順 8.5.6 ベンダーがシステム・コンポーネントのサポートと保守に使用する アカウントが非アクティブで、ベンダーが必要とするときだけ有効にさ れ、使用中は監視されることを確認する。 8.5.7 上記で選択したユーザーID のサンプルとユーザーに対する質 問から、ユーザーがパスワード手順を理解しているかを確認する。 対 応 未対応 目標期日／コメント 8.5.8.a システム・コンポーネントのサンプル（サンプルの番号または記 述、もしくはその両方を記入）について、ユーザーID リストをレビュー し、次の項目を確認する。 ● 汎用 ID およびアカウントは無効になっているか、削除されている。 ● システム・アドミニストレーション活動や他の重要な機能に関する共 有 ID は存在しない。 ● 無線 LAN およびデバイスのアドミニストレーションに共有および汎 用 ID が使用されていない。 8.5.8.b パスワード手順をレビューして、グループおよび共有パスワー ドが明示的に禁止されていることを確認する。 8.5.8.c システム・アドミニストレータにインタビューして、グループおよ び共有パスワードが、たとえ求められても、付与されないことを確認す る。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 29 PCI セキュリティ監査手順 強固なアクセス制御手法の導入 要 件 8.5.9 ユーザー・パスワードを、 少なくとも 90 日ごとに変更す る。 8.5.10 最小パスワード長は 7 文字以上にする。 8.5.11 数字と英字の組み合わ せからなるパスワードを使用す る。 テスト手順 8.5.9 システム・コンポーネントのサンプル（サンプルの番号または記 述、もしくはその両方を記入）について、（現在日付を記入）現在のシス テム構成設定を入手および検査して、ユーザー・パスワードのパラメー タが、少なくとも 90 日ごとのパスワード変更をユーザーに求めるように設 定されていることを確認する。 サービス・プロバイダのみ。内部プロセスと顧客／ユーザードキュメンテ ーションのレビューを通じて、顧客パスワードの定期的な変更が必須 で、かついつ、どんな状況のもとでパスワードを変更する必要があるか に関する指針が顧客に与えられているかを確認する。 8.5.10 システム・コンポーネントのサンプル（サンプルの番号または記 述、もしくはその両方を記入）について、（現在日付を記入）現在のシス テム構成設定を入手および検査して、パスワードのパラメータが、7 文 字以上のパスワードを求めるように設定されていることを確認する。 サービス・プロバイダのみ。内部プロセスと顧客／ユーザードキュメンテ ーションのレビューを通じて、顧客パスワードが最小長の要件を満たす ことが求められているかを確認する。 8.5.11 システム・コンポーネントのサンプル（サンプルの番号または記 述、もしくはその両方を記入）について、（現在日付を記入）現在のシス テム構成設定を入手および検査して、パスワードのパラメータが、数字 と英字の両方を含んだパスワードを求めるように設定されていることを確 認する。 サービス・プロバイダのみ。内部プロセスと顧客／ユーザードキュメンテ ーションのレビューを通じて、顧客パスワードが数字と英字の両方を含 むことが求められているかを確認する。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 対 応 未対応 目標期日／コメント 30 PCI セキュリティ監査手順 強固なアクセス制御手法の導入 要 件 8.5.12 直近 4 回に使用された のと同じパスワードは、新しいパ スワードとして使用できないよう にする。 8.5.13 ユーザーID をロックア ウトすることにより、連続したアク セス試行を６回以内に制限す る。 8.5.14 ロックアウト期間は、30 分間またはアドミニストレータが ユーザーID を有効にするまで とする。 テスト手順 8.5.12 システム・コンポーネントのサンプル（サンプルの番号または記 述、もしくはその両方を記入）について、（現在日付を記入）現在のシス テム構成設定を入手および検査して、パスワードのパラメータが、新し いパスワードが直近 4 回使用されたものと同じであってはならないことを 求めるように設定されていることを確認する。 サービス・プロバイダのみ。内部プロセスと顧客／ユーザードキュメンテ ーションのレビューを通じて、新しい顧客パスワードが直近 4 回のパスワ ードと同じであってはならないことが求められているかを確認する。 8.5.13 システム・コンポーネントのサンプル（サンプルの番号または記 述、もしくはその両方を記入）について、（現在日付を記入）現在のシス テム構成設定を入手および検査して、パスワードのパラメータが、6 回よ り多くログオン試行された場合、ユーザーのアカウントをロックアウトする ように設定されていることを確認する。 サービス・プロバイダのみ。内部プロセスと顧客／ユーザードキュメンテ ーションのレビューを通じて、顧客パスワードを 6 回より多くログオン試 行された場合、一時的にロックアウトすることが求められているかを確認 する。 8.5.14 システム・コンポーネントのサンプル（サンプルの番号または記 述、もしくはその両方を記入）について、（現在日付を記入）現在のシス テム構成設定を入手および検査して、パスワードのパラメータが、ユー ザー・アカウントのロックアウトは、30 分間またはシステム・アドミニストレ ータがアカウントをリセットするまで続くことを求めるように設定されてい ることを確認する。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 対 応 未対応 目標期日／コメント 31 PCI セキュリティ監査手順 強固なアクセス制御手法の導入 要 件 8.5.15 セッションのアイドル時 間が 15 分を超えた場合、ユー ザーは端末を再び利用するた めにパスワードを入力し直さな ければならないようにする。 8.5.16 カード会員情報を保管 するデータベースへのすべて のアクセスを認証する。これに は、アプリケーション、アドミニス トレータ、他のすべてのユーザ ーによるアクセスが含まれる。 テスト手順 8.5.15 システム・コンポーネントのサンプル（サンプルの番号または記 述、もしくはその両方を記入）について、（現在日付を記入）現在のシス テム構成設定を入手および検査して、システム／セッションが未稼働で ある場合のタイムアウト機能が 15 分間に設定されていることを確認す る。 8.4.16.a データベースのサンプル（番号を記入）について、データベ ース構成設定をレビューし、個人、アプリケーション、アドミニストレータ を含むアクセスが認証されることを確認する。 8.4.16.b データベース構成設定とデータベース・アカウントをレビュー して、データベースに対する直接的な SQL クエリーが禁止されているこ とを確認する（個人のデータベース・ログイン・アカウントはごく少数に し、データベース・アドミニストレータに限る必要がある）。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 対 応 未対応 目標期日／コメント 32 PCI セキュリティ監査手順 強固なアクセス制御手法の導入 要 件 テスト手順 対 応 未対応 目標期日／コメント 要件 9: カード会員情報へアクセスする際、物理的なアクセスを制限すること カード会員データまたはそれを保管するシステムへの物理的アクセスは、装置またはデータにアクセスしたり、システムを取り除いたり、ハードコピーを取ったりする機会を 与えることになるため、適切に制限される必要がある。 9.1 カ ード 会員 情報 を格納 、 処 9.1 各コンピュータ・ルーム、データ・センター、その他、カード会員情報 理、または伝送するシステムへの が保管されたシステムが存在する物理エリアについて、次の物理セキュリ 物理的アクセスを制限および監視 ティ管理が存在することを確認する。 するために、適切な施設立ち入り ● バッジ・リーダーと認証バッジ、ロックとキー、その他によって、アクセス 管理を実施する。 する必要があることを確認する。 ● システム・アドミニストレータに、カード会員環境からランダムに選択さ れた 3 つのシステムのコンソールにログインさせ、それらが不正使用を 防ぐために「ロック」されることを確認する。 9.1.1 カード会員情報が格納されたり、存在するデータ・センターの出 9.1.1 機密エリアはカメラを使 入口を監視するビデオ・カメラがあることを確認する。ビデオ・カメラはデ 用して監視する。このデータを ータ・センター内にあるか、改ざんまたは無効化に対して保護されてい 監査し他の項目と関連付ける。 る必要がある。カメラが監視され、カメラからのデータが少なくとも 3 か月 データは法律による制限がない 間保管されているかを確認する。 かぎり、少なくとも 3 か月間保管 する。 9.1.2 ネットワーク・アドミニストレータへの質問と観察により、ネットワー 9.1.2 誰でもアクセス可能なネ ク・ジャックは、許可を受けた従業員が必要な場合のみ有効にできるよう ットワーク・ジャックへの物理的 になっているかを確認する。たとえば、訪問者を受け入れる会議室で アクセスを制限する。 は、DHCP が有効になったネットワーク・ポートがあってはならない。ま た、訪問者がアクティブなネットワーク・ジャックのあるエリアに入るとき は、必ず案内者が同伴すること。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 33 PCI セキュリティ監査手順 強固なアクセス制御手法の導入 要 件 9.1.3 無線アクセス・ポイント、 ゲートウェイ、ハンドヘルドデバ イスへの物理的アクセスを制限 する。 9.2 特にカード会員情報にアクセ ス可能なエリアにおいて、すべて の担当者が従業員と訪問者を容 易に区別するのに役立つ手順を 作成する。「従業員」とは、フルタイ ムまたはパートタイムの従業員、派 遣従業員／作業員、現場に常駐 するコンサルタントのことである。 「訪問者」とは、ベンダー、従業員 のゲスト、サービス作業員、短時 間（通常は 1 日を超えない）施設 に立ち入る必要のある人々のこと である。 9.3 すべての訪問者に対して次 のことを徹底する。 9.3.1 カード会員情報が処理ま たは保管されるエリアに立ち入 る際は、事前に許可を受ける。 9.3.2 有効期限があり、従業員 ではないことを識別する物理ト ークン（例：、バッジ、アクセス・ デバイス）を着用させる。 テスト手順 9.1.3 無線アクセス・ポイント、ゲートウェイ、ハンドヘルドデバイスへの 物理アクセスが適切に制限されていることを確認する。 対 応 未対応 目標期日／コメント 9.2.a 従業員、協力会社社員、訪問者にバッジを与えるためのプロセスを レビューし、次の項目が含まれているかを確認する。 ● 新しいバッジを与えるため、アクセス要件を変更するため、離職した従 業員や期限が切れた訪問者のバッジを取り消すためのプロセス。 ● バッジ・システムへのアクセス制限。 9.2.b 施設内の人々を観察して、従業員と訪問者を容易に区別できるか を確認する。 9.3 次の従業員／訪問者管理が存在することを確認する。 9.3.1 訪問者を観察して、ID バッジの使用を確認する。データ・センタ ーへのアクセスを試み、訪問者の ID バッジでは、カード会員情報を格 納した物理エリアへは案内者の同伴なしには入れないことを確認する。 9.3.2 従業員と訪問者のバッジを観察して、ID バッジにより、従業員と 訪問者／外部者が明確に区別できること、および訪問者のバッジに有 効期限が設定されていることを確認する。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 34 PCI セキュリティ監査手順 強固なアクセス制御手法の導入 要 件 9.3.3 施設を退去するとき、ま たは有効期限切れの際に物理 トークンの返却を求める。 9.4 訪問者ログを使用して訪問者 の活動に関する物理監査証跡を 記録する。このログは、法律による 制限がないかぎり少なくとも 3 か月 間保管する。 9.5 バックアップの媒体は、安全 なオフサイト施設に保管する。オフ サイト施設としては、外部の施設を 使用する。 9.6 カード会員情報が記録された 紙および電子媒体（例：コンピュー タ、電子媒体、ネットワークおよび 通 信 ハ ー ド ウ ェア 、 電 気 通 信 回 線、紙のレシート、レポート、ファッ クス）を物理的に保護する。 9.7 カード会員情報が記録され た、あらゆる種類の媒体の内外へ の配送を、厳格に管理する。 9.7.1 機密情報を含んだ媒体 には、そのことを示すラベルを 貼付する。 9.7.2 媒体を送付する際は、正 確な追跡が可能な配送機関ま たはその他の手段を使用する。 テスト手順 9.3.3 施設を出る訪問者を観察して、訪問者が退出時または有効期限 切れ時に ID バッジの返却を求められることを確認する。 対 応 未対応 目標期日／コメント 9.4 カード会員情報が格納または伝送される施設およびコンピュータ・ル ームへの物理アクセスについて、訪問者ログが作成されていることを確認 する。ログは、訪問者の氏名、勤務先、物理アクセスを許可した従業員を 含んでおり、少なくとも 3 か月間保管されていることを確認する。 9.5 バックアップに関するポリシーと手順をレビューし、オフサイト格納施 設を訪問して、バックアップの媒体が物理的に安全な耐火性のオフサイト 場所に保管されていることを確認する。 9.6 カード会員情報が記録されたすべての紙および電子媒体を保護する ためのポリシーと手順を入手する。プロセスには、コンピュータ・ルームとデ ータ・センターにある紙および電子媒体、ならびに従業員のデスクやオー プン作業スペースにあるレシート、レポート、ファックス、CD、ディスクに関 する管理が含まれていることを確認する。 9.7 カード会員情報の配布を管理するためのポリシーが存在し、そのポリ シーが個人に配布されたものを含むすべての配布媒体をカバーし、かつ 次の項目を求めていることを確認する。 9.7.1 すべての媒体には、「機密」であることが識別できるようにラベル を貼付する必要がある。 9.7.2 施設外に送られるすべての媒体は、記録を取り、管理権限者に よる許可を受け、安全な配送機関または追跡可能な他の配送メカニズ ムを通じて送る。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 35 PCI セキュリティ監査手順 強固なアクセス制御手法の導入 要 件 9.8 安全なエリアの外へ媒体がも ちだされる場合（特に媒体を個人 に配布される場合）は、すべて管 理権限者の承認を得る。 9.9 カード会員情報が記録された 媒体の保管とアクセスを厳格に管 理する。 9.9.1 すべての媒体の在庫を 適切に管理し、安全に保管す る。 9.10 カード会員情報が記録され た媒体を業務上または法律上不 必要になった場合、破壊する。 9.10.1 ハードコピー資料は、ク ロスカット裁断、焼却、またはパ ルプ状に溶解する。 9.10.2 電子媒体を、カード会 員情報が再現不可能になるよう に、消去、消磁、裁断、または 破壊する。 テスト手順 9.8 直近数日分のオフサイト媒体の追跡ログのサンプルを選択して、詳細 追跡情報と適切な管理権限者の承認が存在するかを確認する。 対 応 未対応 目標期日／コメント 9.9 ハードコピーと電子媒体の保管と保守を管理するためのポリシーを入 手し、そのポリシーが定期的な媒体目録作成を求めているかを確認する。 次の項目を実行して、関連プロセスを検証する。 9.9.1.a メディア在庫記録を入手およびレビューして、在庫記録の作成 が定期的に実行されていることを確認する。 9.9.1.b 媒体の安全な格納を確認するために実施されているプロセス を入手およびレビューする。 9.10.a 定期的な媒体破壊ポリシーを入手し、カード会員情報を持つすべ ての媒体がカバーされていることを確認する。 9.10.b さらに次の項目を実行する。 9.10.1.a ハードコピー資料が ISO 9564-1 または ISO 11568-3 に従っ てクロスカット裁断、焼却、またはパルプ状に溶解されているかを確認 する。 9.10.1.b 破壊される情報のストレージ・コンテナを観察し、コンテナの セキュリティが保たれていることを確認する。たとえば、「裁断予定」コン テナは、内容へのアクセスを防止するために鍵がかけられているかを確 認する。 9.10.2 電子メディアは、軍用消去プログラムを使用したファイル削除、 消磁、その他物理的メディア破壊により、復元不可能な状態まで破壊さ れることを確認する。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 36 PCI セキュリティ監査手順 定期的なネットワークの監視およびテスト 要 件 テスト手順 対 応 未対応 目標期日／コメント 要件 10：ネットワーク資源およびカード会員情報に対するすべてのアクセスを追跡し、監視すること ログのメカニズムとユーザー活動の追跡機能は重要である。すべての環境にログが存在することにより、もし何らかの不都合が起こったとき、詳しい追跡と分析が行える。シ ステム稼動ログがないとセキュリティ危殆の原因の追求が非常に難しくなる。 10.1 システム・コンポーネントに対す 10.1 システム・アドミニストレータの観察と質問を通じて、無線ネットワ るすべてのアクセス（特にルートなどの ークとの接続に関するものを含む、監査証跡が確立され、運用状態に アドミニストレータ権限を持つユーザ あることを確認する。 ーによるもの）と個々のユーザーをリン クするためのプロセスを確立する。 10.2 すべてのシステム・コンポーネン 10.2 質問、システム・コンポーネントのサンプル（サンプルの番号また トに対して、次のイベントを追跡するた は記述、もしくはその両方を記入）に関する（現在日付を記入）の監査 ログのレビューと監査ログ設定のレビューを通じて、次のイベントが記 めの自動監査証跡を実装する。 録されていることを確認する。 10.2.1 カード会員情報に対するす 10.2.1 カード会員情報へのアクセスの記録。 べての個人アクセス。 10.2.2 ルートまたはアドミニストレータ権限を持つ個人による活動 10.2.2 ルートまたはアドミニストレ の記録。 ータ権限を持つ個人が行ったすべ ての操作。 10.2.3 すべての監査証跡へのアク 10.2.3 すべての監査証跡へのアクセスの記録。 セス。 10.2.4 無 効 な 論 理 的 ア ク セ ス 試 10.2.4 無効な論理的アクセス試行の記録。 行。 10.2.5 識別および認証メカニズム 10.2.5 識別および認証メカニズムの使用の記録。 の使用。 10.2.6 監査ログの初期化。 10.2.6 監査ログの初期化の記録。 10.2.7 システムレベルのオブジェ 10.2.7 システムレベルのオブジェクトの作成と削除の記録。 クトの作成と削除。 10.3 すべてのシステム・コンポーネン 10.3 質問と観察を通じて、上記 10.2 に記述された個々の監査可能 トにおいて、各イベントごとに少なくと なイベントについて、監査証跡が次の情報を記録していることを確認 する。 も次の監査証跡を記録する。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 37 PCI セキュリティ監査手順 定期的なネットワークの監視およびテスト 10.3.1 10.3.2 10.3.3 10.3.4 要 件 ユーザー識別。 イベントのタイプ。 日付と時刻。 成功または失敗の表示。 10.3.5 イベントの起点。 10.3.6 影響を受けるデータ、シス テム・コンポーネント、または資源の 識別子または名前。 テスト手順 対 応 未対応 目標期日／コメント 10.3.1 ユーザー識別。 10.3.2 イベントのタイプ。 10.3.3 日付と時刻。 10.3.4 成功または失敗の表示。無線接続に関する成功または失 敗を含む。 10.3.5 イベントの起点。 10.3.6 影響を受けるデータ、システム・コンポーネント、または資源 の識別子または名前。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 38 PCI セキュリティ監査手順 定期的なネットワークの監視およびテスト 要 件 テスト手順 10.4 すべての重要なシステム・ク 10.4 組織内で正しい時刻を入手および配布するためのプロセスを入手 ロックと実際の時刻を同期させる。 およびレビューする。また、システム・コンポーネントのサンプル（サンプル の番号または記述、もしくはその両方を記入）について、関連するシステ ム・パラメータの設定を入手およびレビューする。次の項目がプロセスに含 まれ、実装されていることを確認する。 ● NTP または類似する技術が時刻同期に使用されている。 ● 組織内の複数の中央タイム・サーバーが外部時刻信号（特殊ラジオ、 GPS 衛星、または他の外部ソースから直接 － 国際原子時刻と UTC（旧 GMT）に基づく）を受信し、時刻精度を保つために互いに 対等な関係にあり、他の内部サーバーと時刻を共有している（すなわ ち、内部サーバーのすべてが外部ソースから信号を受信するわけで はない）。 ● NTP が最新バージョンで実行されている。 ● タイム・サーバーが NTP 時刻更新を受け取る相手として特定の外部 ホストが指定されている（攻撃側がクロックを変えるのを防ぐ）。オプシ ョンで、更新は対称キーにより暗号化され、NTP サービスの供給を受 けるクライアント・マシンの IP アドレスを指定するアクセス・コントロー ル・リストを作成する（内部タイム・サーバーの不正使用を防ぐため）。 詳しくは、www.ntp.org を参照。 10.5 監査証跡は改変できないよ 10.5 システム・アドミニストレータへの質問とファイル・パーミッション（アク うに次のような手段により保護す セス権限）のレビューを通じて、次の項目を確認する。 る。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 対 応 未対応 目標期日／コメント 39 PCI セキュリティ監査手順 定期的なネットワークの監視およびテスト 要 件 10.5.1 監査証跡の閲覧はそれ が業務上必要な人々に制限す る。 10.5.2 監査証跡ファイルは改 ざんされないように保護する。 10.5.3 監査証跡ファイルを、改 ざんが難しい集中ログ・サーバ ーまたは媒体に直ちにバックア ップする。 10.5.4 無線ネットワークのログ を、内部 LAN 上のログ・サーバ ーにコピーする。 10.5.5 既存のログ・データが改 ざんされたときに必ず警報が発 せられるように、ログに対してフ ァイル完全性監視／変更検出 ソフトウェア（Tripwire など）を 使用する（新しいデータの追加 に対しては、警報は起こらな い）。 10.6 すべてのシステム・コンポー ネントのログを少なくとも一日 1 回 はレビューする。ログのレビューの 対象には、IDS などのセキュリティ 機能を実行するサーバーや認証 （AAA）サーバーなどが含まれる。 テスト手順 10.5.1 業務上必要な個人のみが監査証跡ファイルを見ることができ る。 対 応 未対応 目標期日／コメント 10.5.2 現行の監査証跡ファイルは、アクセス・コントロール・メカニズ ム、物理的分離、ネットワーク分離などによって、不正変更から保護され ている。 10.5.3 現行の監査証跡ファイルを、集中ログ・サーバーまたは改ざん が難しい媒体に直ちにバックアップする。 10.5.4 無線ネットワークに関するログを集中内部サーバーまたは改ざ んが難しい媒体にオフロードまたはコピーする。 10.5.5 システム設定および監視対象ファイル、ならびに監視活動の結 果を観察することにより、ログに関するファイル完全性監視または変更 検出ソフトウェアの使用を確認する。 10.6.a セキュリティ・ポリシーおよび手順を入手し、ログを少なくとも毎日レ ビューするための手順が含まれ、かつ例外に対するフォローアップが要求 されていることを確認する。 10.6.b 観察とインタビューを通じて、通常のログ・レビューがすべてのシス テム・コンポーネントに対して実行されていることを確認する。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 40 PCI セキュリティ監査手順 定期的なネットワークの監視およびテスト 要 件 テスト手順 対 応 未対応 目標期日／コメント 10.7 監査証跡履歴は、その利用 10.7.a セキュリティ・ポリシーおよび手順を入手し、監査ログの保管ポリシ が必要とされる期間、かつ法律で ーを含んでおり、監査ログの少なくとも 1 年間の保管を求めていることを確 認する。 許される範囲内で保管する。 通常、監査履歴は少なくとも 1 年 10.7.b システム・コンポーネントのサンプル（サンプルの番号または記述、 間保管し、少なくとも 3 か月間はオ もしくはその両方を記入）について、監査ログがオンラインもしくはテープ 上で少なくとも 1 年間利用可能であることを確認する。 ンラインで利用できるようにする。 要件 11：セキュリティ・システムおよび管理手順を定期的にテストすること 脆弱性はハッカー／研究者によって常に発見されており、新しいソフトウェアによって持ち込まれる。システム、プロセス、カスタム・ソフトウェアを、そのセキュリティが、一定 期間および複数の変更を経て確保されるまで、十分なテストをする必要がある。 11.1 セキュリティ管理、制限、ネッ 11.1.a セキュリティ担当者への質問を通じて、カード会員環境内の装置 トワーク接続、制約といった機能 に対して定期的セキュリティ・テストが行われているかを確認する。 を、不正アクセス試行を十分に識 11.1.b 使用されているすべての無線デバイスを識別するために、無線ア 別または停止できるように、定期 ナライザが定期的に使用されているかを確認する。 的にテストする。無線技術が導入 11.1.c サービス・プロバイダのみ。関連するコード、ドキュメンテーション、 されている場合、無線アナライザ プロセスを調査して、不正トランザクション試行を検出するために、ベロシ を定期的に使用して、使用中のす ティ・チェックやその他のトランザクション・トレンド・データがリアルタイムで べての無線装置を識別できるよう 監視および収集されていることを確認する。 にする。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 41 PCI セキュリティ監査手順 定期的なネットワークの監視およびテスト 要 件 11.2 内部または外部のネットワー ク脆弱性スキャンを少なくとも四半 期ごと、およびネットワークの大き な変更（例：、新しいシステム・コン ポーネントの導入、ネットワーク・ト ポロジの変更、ファイアウォール・ ルールの修正、製品のアップグレ ード）の後に実施する。外部の脆 弱性スキャンは、カード業界により 認定されたスキャン・ベンダーによ って行われなければならない。 テスト手順 11.2.a ネットワーク、ホスト、アプリケーションに対する過去 4 回の四半期 脆弱性スキャンの出力を調査して、カード会員環境内の装置のセキュリテ ィ・テストが定期的に実行されていることを確認する。スキャン・プロセスに 「クリーン」な結果が得られるまでの再スキャンが含まれていることを確認す る。 11.2.b PCI セキュリティ・スキャニング手順に従って外部スキャンが四半期 ごとに実行されていることを確認するために、過去 4 回の四半期外部脆弱 性スキャンの出力を調査して、次の項目を確認する。 ● 過去 12 か月に実行された 4 回の四半期スキャン。 ● 各スキャンの結果が PCI セキュリティ・スキャニング対応（例：非緊急、 重大、または高い脆弱性）が含まれていること。 ● PCI セキュリティ・スキャニング手順の実行を認可されたベンダーによ ってスキャンが行われていること。 11.3 ネットワークのインフラストラ 11.3 最新の侵入テストの結果を入手して、侵入テストが少なくとも一年に クチャとアプリケーションに対する 1 回および環境の大きな変更の後に実行されていることを確認する。脆弱 侵入テストを少なくとも一年に 1 性が見つかった場合、修正されていることを確認する。 回、およびインフラストラクチャまた はアプリケーションの大きなアップ グレードまたは変更（例：オペレー ティング・システムのアップグレー ド、サブネットワークの追加、Web サーバーの追加）の後に実施す る。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 対 応 未対応 目標期日／コメント 42 PCI セキュリティ監査手順 テスト・ネットワークを定期的に監視する 要 件 11.4 ネットワーク侵入検出システム、ホ ストベース侵入検出システム、または侵 入防止システム、もしくはその複数を使 用して、すべてのネットワーク・トラフィッ クを監視し、セキュリティ危殆の疑いが ある場合、担当者に警告する。すべて の侵入検出および防止エンジンを最新 の状態に保つ。 11.5 ファイル完全性の監視を導入し て、重要なシステムまたはコンテンツ・フ ァイルに不正改ざんがあった場合、担 当者に警告する。重要ファイルの比較 を少なくとも一日に１回（プロセスが自 動化可能な場合はもっと頻繁に）実行 する。重要なファイルは、カード会員情 報を含んだファイルだけとは限らない。 通常、ファイル完全性の監視の対象と なる重要なファイルは、通常は変更され ず、万が一変更された場合、システム のセキュリティが危殆したことまたはそ のリスクがあるファイルのことである。一 般にファイル完全性監視のために使用 される製品は、対象となるオペレーティ ング・システムの重要なファイルに合わ せてあらかじめ設定されている。カスタ ム・アプリケーションのファイルなど、他 の重要なファイルに対しては、加盟店ま たはサービス・プロバイダが評価しなけ ればならない。 テスト手順 11.4 ネットワーク上でネットワーク侵入検出／防止ソフトウェアが使 用されているかを調べる。IDS または IPS、もしくはその両方を使用 して、ネットワークを監視し、セキュリティ危殆の疑いがある場合に担 当者に警告する仕組みになっていることを確認する。 ファイル完全性監視を導入して、重要なシステムまたはコンテンツ・フ ァイルの不正改ざんがあった場合、担当者に警告し、重要ファイルの 比較を少なくとも一日に 1 回（プロセスが自動化可能な場合はもっと 頻繁に）実行する。 11.5 システム設定と監視対象ファイルを調べ、監視活動の結果をレ ビューして、ファイル完全性監視製品の使用を確認する。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 対 応 未対応 目標期日／コメント 43 PCI セキュリティ監査手順 情報セキュリティ・ポリシーの整備 要 件 テスト手順 対 応 未対応 目標期日／コメント 要件 12：情報セキュリティに関するポリシーを整備すること 強力なセキュリティ・ポリシーにより、会社全体のセキュリティへの認識レベルが決定され、従業員が何を行うべきかを理解できるようになる。すべての従業員は、データの機 密性とそれを保護する責務を認識する必要がある。 12.1 次のようなセキュリティ・ポリ 12.1 情報セキュリティ・ポリシーを読み、ポリシーが関連するすべてのシス シーを確立、公開、維持、普及す テム・ユーザー（ベンダー、協力会社、ビジネス・パートナーを含む）に周 知徹底されているかを確認する。 る。 12.1.1 この仕様にあるすべて 12.1.1 ポリシーには、この仕様にあるすべての要件が記述されている の要件に対応している。 こと。 12.1.2 情報セキュリティ・ポリシーは、脅威、脆弱性を識別するための 12.1.2 脅 威 と 脆 弱 性 を 識 別 年間リスク評価プロセスを含んでおり、正式なリスク評価の実績となって し、形式化されたリスク評価を実 いること。 現する年間プロセスを含んでい る。 12.1.3 情報セキュリティ・ポリシーは、少なくとも一年に 1 回レビューさ 12.1.3 少なくとも一年に 1 回の れ、業務目的またはリスク環境の変更を反映するために、必要に応じて レビューと環境変更時の更新を 更新される。 含んでいる。 12.2 この仕様の要件に適合した 12.2.a 毎日の運用セキュリティ手順をレビューする。手順がこの仕様に準 毎日の運用セキュリティ手順（例： 拠し、各要件についてアドミニストレータおよび技術手順を規定しているこ ユーザー・アカウント保守手順、ロ とを確認する。 グ・レビュー手順）を作成する。 12.3 すべての従業員と協力会社 12.3 モデム使用ポリシーを入手および調査し、次の項目を指定／要求し を対象として、モデムや無線など、 ていることを確認する。 担当者が接する重要な技術の適 切な使用を規定するために、それ らの技術に関するポリシーを作成 する。これらの使用ポリシーには、 次のような項目が必要である。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 44 PCI セキュリティ監査手順 情報セキュリティ・ポリシーの整備 要 件 12.3.1 管理権限者による明示的な 承認。 12.3.2 技術の使用に対する認証。 12.3.3 装置およびアクセスを持つ 担当者のリスト。 12.3.4 装置の所有者、連絡先、目 的のラベル表示。 12.3.5 技術の許される使い方。 12.3.6 これらの技術が許されるネ ットワーク上の場所。 12.3.7 会社が承認した製品のリス ト。 12.3.8 非活性状態が特定期間続 いた後のモデム・セッションの自動 切断。 12.3.9 ベンダー用モデムはベンダ ーが必要とする時のみの活性化 し、使用後に直ちに非活性化する。 12.3.10 モデムを通じて遠隔よりカ ード会員情報にアクセスする場合、 ローカル・ハード・ドライブ、フロッ ピ・ディスク、または他の外部媒体 へのカード会員情報の格納を無効 にする。また、リモート・アクセス中 は、カットアンドペーストおよび印刷 機能を無効にする。 テスト手順 12.3.1 装置を使用するための管理権限者による明示的な承認。 対 応 未対応 目標期日／コメント 12.3.2 すべての装置の使用は、ユーザー名とパスワードまたは他 の検証項目（例：トークン）によって認証される。 12.3.3 すべての装置および装置の使用を許可されたすべての担 当者のリスト。 12.3.4 装置の所有者、連絡先、目的のラベル表示。 12.3.5 技術の許される使い方。 12.3.6 技術が許されるネットワーク上の場所。 12.3.7 会社が承認した製品のリスト。 12.3.8 非活性状態が特定期間続いた後のモデム・セッションの自 動切断。 12.3.9 ベンダーが使用するモデムはベンダー必要時のみ活性化 し、使用後に直ちに非活性化する。 12.3.10 モデムを通じて遠隔からカード会員情報にアクセスする場 合、カード会員情報のローカルのハード・ディスク・ドライブ、フロッ ピ・ディスク、または他の外部メディアへの格納の無効化。また、リモ ート・アクセス中のカットアンドペーストおよび印刷機能の無効化。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 45 PCI セキュリティ監査手順 情報セキュリティ・ポリシーの整備 要 件 12.4 セキュリティ・ポリシーおよび 手順において、すべての従業員と 協力会社の情報セキュリティに関 する責務を明確に定義するように する。 12.5 個人またはチームに、次の ような情報セキュリティ管理責務を 割り当てる。 テスト手順 12.4 情報セキュリティ・ポリシーにおいて、従業員と協力会社の情報セキ ュリティに関する責務を明確に定義しているかを確認する。 対 応 未対応 目標期日／コメント 12.5 チーフ・セキュリティ・オフィサまたは他にセキュリティに熟知した管 理権限者に情報セキュリティ対応が正式に割り当てられていることを確認 する。情報セキュリティのポリシーと手順を入手して、次の情報セキュリティ 責務が個別および正式に割り当てられていることを確認する。 12.5.1 セキュリティ・ポリシーおよび手順の作成と配布が正式に割り当 12.5.1 セキュリティ・ポリシーお てられている。 よび手順の確立、文書化、配 布。 12.5.2 セキュリティ警報の監視と分析、および適切な情報セキュリティ 12.5.2 セキュリティ警報および および業務ユニット管理者への情報の配布。 情報の監視および分析、適切 な担当者への配布。 12.5.3 セキュリティ事故対応および報告手順の作成と配布が正式に指 12.5.3 あらゆる状況をタイムリ 定されていること。 ーかつ効果的に取り扱うため の、セキュリティ事故の対処およ び報告手順の確立、文書化、 配布。 12.5.4 ユーザー・アカウントと認証管理の管理権限が正式に割り当て 12.5.4 追加、削除、変更の対 られていること。 応を含むユーザー・アカウント の管理。 12.5.5 データに対するすべて 12.5.5 データへのすべてのアクセスの監視と制御が正式に割り当てら のアクセスの監視と制御。 れていること。 12.6 すべての従業員にカード会 12.6 セキュリティ管理プログラムドキュメンテーションを入手し、次のコンポ 員情報の情報セキュリティの重要 ーネントが含まれているかを確認する。 性を認識させる。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 46 PCI セキュリティ監査手順 情報セキュリティ・ポリシーの整備 要 件 12.6.1 従業員を教育する（例： ポスター、通知書、メモ、ミーテ ィング、プロモーションを通じ て）。 12.6.2 従業員に対して、会社 のセキュリティ・ポリシーおよび 手順を読み、理解したことの、 書面による確認を求める。 12.7 内部ソースからの攻撃のリス クを最小限に抑えるために、従業 員を検査する。店のレジ係など、ト ランザクションを処理するために、 一度に 1 つのカード番号にアクセ スするだけの従業員の場合、この 要件は推奨のみである。 12.8 カード会員情報にアクセス する外部委託先に対して、カード 業界のセキュリティ要件に準拠す るように契約で求める。契約書に は、少なくとも次の事項を記述す る。 12.8.1 第三者が、自分が保有 するカード会員情報のセキュリ ティに対し、外部委託先が責任 を持っているということの認識。 テスト手順 12.6.1 知識の伝達および従業員を教育するための複数の手段（ポスタ ー、通知書、ミーティングなど）。 対 応 未対応 目標期日／コメント 12.6.2 従業員が会社の情報セキュリティ・ポリシーを読み、理解したこ との、書面による確認を求めること。 12.7 人事部に問い合わせ、システム、ネットワーク、またはカード会員情 報にアクセスできる可能性のある従業員の経歴チェックを行うためのプロ セスが実施されているかを確認する。この経歴チェックには、職歴、犯罪 履歴、クレジット履歴、身元保証人のチェックが含まれる。 注）本要件は法令の範囲内、もしくは国ごとの事情に応じ対応される。 12.8 組織とカード会員情報を取り扱う外部委託先（例：バックアップ・テー プ・ストレージ施設、Web ホスティング会社やセキュリティ・サービス・プロバ イダなどの管理サービス・プロバイダ、もしくは不正モデリング目的でデー タを受け取る会社）との間の契約を入手する。組織と外部委託者との間の 業務関係に関連した PCI 基準の要件が契約に含まれていることを確認す る。特に次の情報が契約に入っていることを確かめる。 12.8.1 契約の条項には、カード会員情報のセキュリティを守る責務に 関し、外部委託者が含まれる。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 47 PCI セキュリティ監査手順 情報セキュリティ・ポリシーの整備 要 件 12.8.2 各決済カード・ブランド、 アクワイアラ、加盟店によるカード 会員情報の所有権は、トランザク ションの完了、ロイヤルティ・プロ グラムのサポート、不正使用管理 サービス、または法律により特に 求められた利用のための使用の みが許されるという認識。 12.8.3 大規模な混乱、災害、ま たは障害が発生したときの業務 の継続。 12.8.4 セキュリティ侵害が起こっ た後に詳しいセキュリティ・レビュ ーを実施するための、カード業 界の代表者、またはカード業界 が承認した監査機関に全面的な 協力とアクセスを与えることを保 障する監査の提供。 12.8.5 外部委託先がカード会 員情報を常に機密データとして 取り扱うことを保障する契約解除 条項の規定。 テスト手順 12.8.2 契約の条項には、カード会員情報の所有と許される使用範囲 が含まれる。 対 応 未対応 目標期日／コメント 12.8.3 契約の条項には、外部委託者のサービスが大規模な混乱ま たは障害が発生したときも利用可能であるなど、外部委託者が適切な 業務継続性を提供することが含まれる。 12.8.4 契約の条項では、カード会員情報のセキュリティが脅かされた 場合、Visa および JCB または Visa もしくは JCB が承認する事業者 による監査を許可する。 12.8.5 契約の条項では、契約解除時およびその後のカード会員情 報の継続的なセキュリティ保持を要求する。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 48 PCI セキュリティ監査手順 情報セキュリティ・ポリシーの整備 要 件 テスト手順 12.9 事故対応計画を導入する。 12.9 事故対応計画と関連手順を入手し、ドキュメンテーションを調査し、 システム侵害に対して迅速に対応 次の項目を実行する。 できるように準備する。 12.9.1 事故対応計画と関連手順に次の項目が含まれているかを確認 12.9.1 システムのセキュリティ する。 危殆の場合に使用する事故対 応計画を策定する。計画では、 ● セキュリティ危殆の場合の役割、責務、連絡に関する戦略。 少なくとも具体的な事故対応プ ● すべての重要システム・コンポーネントに関するカバレージと対応。 ロセス、業務復旧および継続手 ● 少なくとも関連機関とアクワイアラへの通知。 順、データ・バックアップ・プロセ ● セキュリティ危殆後の業務継続のための戦略。 ス、役割と責務、連絡方法（例： ● 関連機関からの事故対応手順の参照と取り込み。 アクワイアラや関連機関への通 ● セキュリティ危殆の報告に関する法的要件の分析（例：カリフォルニ 知）について記述する。 ア州法 1386 条によると、カリフォルニア州の在住者との業務に関し て、データベース内で実際にセキュリティが危殆するか、その疑い がある場合、影響を受ける消費者への通知が要求されている。） 12.9.2 計画を少なくとも一年に 12.9.2 少なくとも一年に 1 回の計画のテスト。 1 回テストする。 12.9.3 観察とポリシーのレビューを通じて、不正活動、重大な IDS 警 12.9.3 セキュリティが脅かされ 告、重要なシステムまたはコンテンツファイルの不正変更に対して、一 た場合の警報に対して、一日 日 24 時間、年中無休の事故対応と証拠の監視カバレージが存在する 24 時間、年中無休で対応する ことを確認する。 担当者を指定する。 12.9.4 観察とポリシーのレビューを通じて、セキュリティ侵害に対して 12.9.4 セキュリティ侵害への対 責任を持つ担当者が定期的にトレーニングを受けていることを確認す 処を担当する担当者に適切なト る。 レーニングを提供する。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 対 応 未対応 目標期日／コメント 49 PCI セキュリティ監査手順 情報セキュリティ・ポリシーの整備 要 件 12.9.5 侵入検出、侵入防止、 ファイル完全性監視システムか らの警報が定義されている。 12.9.6 過去の経験および業界 の最良慣行に基づき事故対応 計画を修正および展開する。 テスト手順 12.9.5 観察とプロセスのレビューを通じて、セキュリティ・システムから の警報の監視とそれに対する対処が事故対応計画に含まれていること を確認する。 12.9.6 観察とポリシーのレビューを通じて、過去の経験および業界の 最良慣行に基づき事故対応計画を修正および展開するプロセスが存 在する。 © 2004 Visa Asia Pacific, Risk Management, Payment Card Industry Security Audit Procedures © 2004 JCB CO.,LTD., Payment Card Industry Security Audit Procedures バージョン 1.0 2004 年 12 月 15 日 対 応 未対応 目標期日／コメント 50