PCI DSS 要件 テスト手順 ガイダンス 信するシステムなどがあります。
6.2 すべてのシステムコンポーネントと ソフトウェアに、ベンダ提供のセキュリ ティパッチがインストールされ、既知の 脆弱性から保護されている。重要なセ キュリティパッチは、リリース後 1 カ月 以内にインストールする。
注: 要件 6.1 で定義されているリスクの
ランク分けプロセスに従って、重要なセ キュリティパッチを識別する必要があり ます。
6.2.a セキュリティパッチのインストールに関連したポリシーと手 順を調べて、以下のプロセスが定義されていることを確認する。
• 該当する、ベンダ提供の重要セキュリティパッチは、リリース 後 1 カ月以内にインストールする。
• 該当する、ベンダ提供のセキュリティパッチをすべて、適切な 時間枠内（3 カ月以内など）にインストールする。.
広く報道されているセキュリティ上の弱点を 使った「0 day」（これまでに知られていなかっ た脆弱性を狙った攻撃）と呼ばれる、それ以外 の攻撃に対しては安全なシステムを狙う攻撃が 次々に出現しています。可能な限り迅速に重要 なシステムに最新のパッチを実装しないと、悪 意のある者によりこれらの弱点が使用され、
ネットワークが攻撃されて使用不可になる可能 性があります。
重要なインフラ用のパッチを優先することで、
高優先度のシステムとデバイスは、パッチがリ リースされ次第脆弱性から保護されるようにな ります。 重要なシステムまたは危険な状態にあ るシステムへのセキュリティパッチを 30 日以内 にインストールされ、その他の危険度の低い パッチは 2 ～ 3 カ月内にインストールするよ う、パッチのインストールに優先順位を付ける ことを検討してください。
この要件は、インストールされているすべての ソフトウェアの該当するパッチに適用されま す。
6.2.b システムコンポーネントおよび関連ソフトウェアのサンプル について、各システムにインストールされたセキュリティパッチの リストと、ベンダの最新のセキュリティパッチのリストを比較し て、以下を確認する。
• 該当する、ベンダ提供の重要セキュリティパッチは、リリース後 1 カ月以内にインストールする。
• 該当するすべてのベンダが提供するセキュリティパッチは、適 切な時間枠（たとえば 3 カ月以内）内に設置されている。
6.3 内部および外部ソフトウェアアプリ ケーション（アプリケーションへの Web ベースの管理アクセスを含む）を次のよ うに開発する。
• PCI DSS （安全な認証やロギングな
ど）に従って。
• 業界基準やベストプラクティスに基 づいて。
• ソフトウェア開発ライフサイクル全 体に情報セキュリティを組み込む。
注：これは、社内開発ソフトウェアすべ て、および第三者によって開発されたカ スタムソフトウェアにも当てはまりま す。
6.3.a 文書化されたソフトウェア開発プロセスを調べて、プロセス が業界標準またはベストプラクティス（あるいはその両方）に基づ いていることを確認する。
ソフトウェア開発の要件定義、設計、分析、お よびテスト段階にセキュリティを含めないと、
セキュリティの脆弱性が過失または故意によっ て本番環境にもたらされる可能性があります。
いつ保存され、送信され、いつメモリに保存さ れるかなど、重要なデータがアプリケーション によってどのように処理されるかを理解する と、データの保護が必要な場所を特定するのに 役立ちます。
6.3.b 記述されたソフトウェア開発プロセスを検査し、ライフサイ クル全体に情報セキュリティが組み込まれていることを確認する。
6.3.c 記述されたソフトウェア開発プロセスを検査し、PCI DSS に 従って、ソフトウェアアプリケーションが開発されていることを確 認する。
6.3.d ソフトウェア開発者のインタビューから、文書化されたソフ トウェア開発プロセスが実装されていることを確認する。
PCI DSS 要件 テスト手順 ガイダンス 6.3.1 アプリケーションがアクティブに
なる前、または顧客にリリースされる 前に、テスト/カスタムアプリケーショ ンアカウント、ユーザ ID、パスワード を削除する
6.3.1 文書化されたソフトウェア開発手順を調べ、責任者をイン タビューすることで、本番前とカスタムアプリケーションアカウ ント、ユーザ ID/パスワードが、システムが本番環境に導入され る、または顧客にリリースされる前に削除されることを確認す る。
開発、テスト/カスタムアプリケーションアカウ ント、ユーザ ID、パスワードは、アプリケー ションがアクティブになる前、または顧客にリ リースされる前に本番環境コードから削除する 必要があります。これらのアイテムは、アプリ ケーションの機能に関する情報を漏洩する場合 があるためです。このような情報を保持してい ると、アプリケーションおよび関連するカード 会員データの侵害を容易にする可能性がありま す。
6.3.2 コーディングの脆弱性がないこと を確認するための、本番または顧客の リリース前のカスタムコードのレ ビューする（手動または自動プロセス による）。
コード変更は、コード作成者以外の、
コードレビュー手法と安全なコーディング 手法の知識のある人がレビューする。
コードレビューにより、コードが安全なコー ディングガイドラインに従って開発されたこ とが保証される
リリース前に、適切な修正を実装してい る。
コードレビュー結果は、リリース前に管理 職によってレビューおよび承認される。
注: このコードレビュー要件は、システ ム開発ライフサイクルの一環として、す べてのカスタムコード（内部および公 開）に適用される。
コードレビューは、知識を持つ社内担当 者または第三者が実施できる。一般に公 開されている Web アプリケーション は、実装後の脅威および脆弱性に対処す るために、PCI DSS 要件 6.6 に定義され ている追加コントロールの対象となる。
6.3.2.a 文書化されたソフトウェア開発手順を調べ、責任者をイン タビューすることで、すべてのカスタムアプリケーションコード の変更は、次のように（手動または自動化されたプロセスのいず れかを使用して）レビューする必要があることを確認する。
コード変更は、コード作成者以外の、コードレビュー手法と安全なコー ディング手法の知識のある人がレビューする。
コードレビューにより、コードが安全なコーディングガイドラインに従って開 発されたことが保証される（PCI DSS 要件 6.5 を参照）。
リリース前に、適切な修正を実装している。
コードレビュー結果は、リリース前に管理職によってレビューおよび承認さ れる。
カスタムコードのセキュリティの脆弱性は、悪 意のある者によってネットワークにアクセス し、カード会員データを侵害するために一般的 に悪用されます。
コードレビューテクニックの知識と経験のある 人がレビューのプロセスに関与する必要があり ます。コードレビューをコードの開発者以外の 担当者に割り当てることにより、独立した客観 的なレビューを実施できます。手動レビューの 代わりに自動ツールやプロセスを使用すること もできますが、自動ツールがコーディング上の 問題を特定することは困難あるいは不可能な場 合があります。
コードが本番環境に導入される、または顧客に リリースされる前にコードエラーを訂正するこ とで、コードが環境を潜在的な侵害にさらすこ とを防止できます。コードエラーは、本番環境 に導入またはリリースした後に対処する場合、
その前に比べてずっと難しく、高価な代償を支 払う結果になります。
リリース前に経営管理者の正式なレビューと承 認を含めることにより、コードが承認され、ポ リシーと手順に従って開発されていることが確 認できます。
6.3.2.b 最近のカスタムアプリケーションの変更についてサンプ ルを選択し、そのカスタムアプリケーションコードが上記6.3.2.a に従ってレビューされていることを確認する。
PCI DSS 要件 テスト手順 ガイダンス 6.4 システムコンポーネントへのすべて
の変更において、変更管理のプロセスお よび手順に従う。これらのプロセスに は、以下を含める必要がある。
6.4 ポリシーと手順を調べ、以下が定義されていることを確認す る。
• 開発/テスト環境が、本番環境から分離されていて、分離を実 施するためのアクセス制御が行われていること
• 開発/テスト環境に割り当てられている担当者と本番環境に割 り当てられている担当者との間で責務が分離されていること
• テストまたは開発に本番環境データ（実際の PAN）を使用し ないこと。
• 本番環境システムがアクティブになる前にテストデータとテス トアカウントが削除されること
• セキュリティパッチやソフトウェアの変更の実装に関連する変 更管理手順が文書化されていること
適切に文書化されて実施されている変更管理が ないと、セキュリティ機能が過失または故意に よって省略あるいは動作不能にされたり、処理 の不規則性が発生したり、悪意のあるコードが 取り込まれる可能性があります。
6.4.1 開発/テスト環境を本番環境から 分離し、分離を実施するためのアクセ ス制御を行う。
6.4.1.a ネットワーク文書とネットワークデバイス構成を調べ て、開発/テスト環境が本番環境から分離されていることを確認す る。
開発およびテスト環境は絶えず状態が変化する ため、本番環境より安全性が低くなります。環 境を適切に分離しないと、テストまたは開発環 境のそれほど厳しくないセキュリティ構成およ び脆弱性のために本番環境およびカード会員 データがリスクにさらされる可能性がありま す。
6.4.1.b アクセス制御設定を調べて、開発/テスト環境と本番環境 の分離を強制するためのアクセス制御が行われていることを確認 する。
6.4.2 開発/テスト環境と本番環境での 責務の分離
6.4.2 プロセスを観察し、開発/テスト環境に割り当てられている 担当者と本番環境に割り当てられている担当者をインタビューす ることで、開発/テスト環境と本番環境の責務が分離されているこ とを確認する。
本番環境およびカード会員データにアクセスで きる担当者の数を少なくすることにより、リス クは最小限に抑えられ、アクセスは業務上必要 とするユーザのみに制限できます。
この要件の目的は、開発/テスト機能を本番機能 から確実に分離することです。たとえば、開発 者は、開発環境では権限を昇格して管理者レベ ルのアカウントを使用し、本番環境では別の ユーザレベルアカウントでアクセスするという 方法があります。
6.4.3 テストまたは開発に本番環境デー タ（実際の PAN）を使用しない
6.4.3.a テストプロセスを観察し、担当者をインタビューすること で、本番環境データ（実際の PAN）がテストまたは開発に使用さ れていないことを確認する。
セキュリティコントロールは、通常、開発環境 ではそれほど厳しくありません。本番環境デー タを使用すると、悪意のある者に本番環境デー タ（カード会員データ）に不正にアクセスする 機会を与えることになります。
6.4.3.b テストデータのサンプルを観察して、本番環境データ
（実際の PAN）がテストまたは開発に使用されていないことを確 認する。