第2話　PCI DSS、いよいよプロジェクトスタートです！

前回第1話では「PCI DSS、どこから手をつければ・・・」と題して、弊社のPCI DSS取り掛かりとしての「PCI DSS準備チーム」の活動をご紹介しました。今回の第2話では、いよいよ弊社での本格的なプロジェクトスタートとなった「GAP分析フェーズ」をご紹介します。

1. GAP分析フェーズ

（1）推進体制

PCI DSS取得のための本格的なスタートは、推進組織である社内プロジェクト「PCI DSSタスクチーム」の設置から始まりました。オーナーは担当役員、エンジニア部門の室長をリーダーとし、専任1名、兼務として社内部門からメンバーが選出され、QSA（Qualified Security Accessors：認証セキュリティ評価機関）ベンダーもオブザーバーとしてプロジェクトに参画する体制となりました。

（2）GAP分析フェーズでの検討事項

PCI DSS認定取得までのロードマップは、プランニングにあたる「GAP分析フェーズ」と、実行アクションにあたる「対策実行フェーズ」、審査機関による「認定審査」の3つのフェーズからなります。

ここではGAP分析フェーズでの検討事項を順を追って紹介します。

（3）スコープ検討

PCI DSSの対象範囲を明確にする「スコープ検討」は、保護すべき情報を洗い出すための最初に行うステップとなります。

以下のラインナップで決済・カードソリューションを提供する弊社としては、全てのソリューションで一気にPCI DSS認定取得を目指すのか、あるいは段階的取得とするのか、その際優先順位をどうするかなどの検討を行いました。

そして、Webクラウドサービス「BLUEBIRD」を先行してPCI DSS認定取得を目指す決定をしました。

理由は、クレジット基幹システムは外部との接続が限定的なのに対して、BLUEBIRDはインターネットに接続するWebクラウドサービスであり、外部からのDoS、DDoS攻撃や不正アクセスなど、セキュリティリスクが非常に高いため、早急な対応が必要との判断によるものです。

（4）非標準項目再評価・洗い出し

ここでは、事前準備で実施した自己問診に対して、QSAコンサルタントの「正しい要件への解釈」によって、PCI DSS要件への対応状況について一つ一つの要件毎に再評価を行いました。

その結果、先だって実施した自己問診に対して、より軽微な対応で認定可能との評価を受けることができました。

（5）対策立案

スコープが決まり、PCI DSS非標準項目が明確になったら、PCI DSS要件を充たすための具体的な対策立案の策定となりました。対策は、「文書・プロセス」と「システム」への二つの切り口からなります。

a) 文書・プロセス

PCI DSSでは、①ポリシーや手順・プロセスの文書化そのものが求められる要件や、②準拠状況確認のための「テスト手順」に文書による手順・プロセスへの結果確認が求められる要件があります。

たとえば、①は「要件12.5.1 セキュリティポリシーおよび手順を確立、文書化、および周知する。」などがこれにあたり、②は「要件1.1.6 ファイアウォールおよびルーターのルールセットは少なくとも6カ月ごとにレビューされる必要がある」へのテスト手順「要件1.1.6.b 文書を入手および調査して、ルールセットが少なくとも6カ月ごとにレビューされることを確認する。」などがこれにあたります。

こうして、約300項目にもなるPCI DSS要件一つ一つに対策を立案しました。

PCI DSS要件	テスト手順	QSA事前評価	対策区分	対策立案
1.1.1 すべてのネットワ－ク接続およびファイアウォ－ル/ル－タ－構成への変更を承認およびテストする正式なプロセス	1.1.1 すべてのネットワ－ク接続およびファイアウォ－ル/ル－タ－構成への変更を承認およびテストする、正式なプロセスがあることを確認する。	対策不要	文書・プロセス	弊社ではITSMS を認証取得しており、その中の変更管理プロセスにて、全ての変更及びその変更に対するテストについてレビュー/承認を行っている。
1.1.3 各インターネット接続、およびDMZ（demilitarized zone）と内部ネットワークゾーンとの間のファイアウォール要件	1.1.3.a ファイアウォール構成基準に、各インターネット接続、および DMZ と内部ネットワークゾーンとの間のファイアウォール要件が含まれていることを確認する。	対策要	文書・プロセス	ファイアウォール構成基準に、クラウドのファイアウォール機能を用いてファイアウォール要件を満たす旨を明記する。
	1.1.3.b 現在のネットワーク図が、ファイアウォール構成基準と一致していることを確認する。	対策要	文書・プロセス	ファイアウォール構成基準を作成後に、現在のネットワーク図が、ファイアウォール構成基準と一致していることを確認する。

その結果、弊社では、16の基準文書作成および関連する運用プロセスの作成および見直しを立案しました。

ここではタイトル名のみのご紹介します。

□基準文書
　【アプリケーション】

PCI DSS運用管理基準
- セキュリティ統制基準
- カード会員データ保護基準
- アプリケーション開発・変更管理基準
- アプリケーションアカウント管理基準
- アプリケーションログ管理基準

　【インフラ】

PCI DSSインフラ管理基準
- ネットワーク構成基準
- オープンネットワーク構成基準
- システム構成基準
- 脆弱性保護基準
- 脆弱性管理基準
- アクセス管理基準
- アカウント管理基準
- 監査証跡管理基準
- セキュリティ検査基準

□運用プロセス

セキュリティ計画書（PCI DSS版）
アプリケーション開発プロセス
変更開発プロセス
各アプリケーション設計書群
CIS標準適用チェックシート
各インフラ設計書群

b) システム

「文書・プロセス」と同様に「システム」についても、PCI DSS要件を一つ一つ分類・整理し、対策立案を策定しました。下記はその一部をわかりやすい例からの抜粋となります。

PCI DSS要件	テスト手順	QSA事前評価	対策区分	対策立案
3.5.2 暗号化キーの保存場所と形式を最小限にし、安全に保存する。	3.5.2.a システム構成ファイルを調査し、キーが暗号化された形式で保存され、キー暗号化キーがデータ暗号化キーとは別個に保存されていることを確認する。	対策要	システム	暗号化システムを導入する。
10.5.5 ログに対してファイル整合性監視または変更検出ソフトウェアを使用して、既存のログデータを変更すると警告が生成されるようにする（ただし、新しいデータを追加する場合は警告を発生させない）。	10.5.5 システム設定、監視対象ファイル、および監視作業からの結果を調査して、ログに対してファイル整合性監視または変更検出ソフトウェアが使用されていることを確認する。	対策要	システム	ログ管理システムを構築する。

「システム」の対策立案に際しては、【既存システムへの手直し】での対応とするか、あるいは【新規に導入・構築】するかを、実現性、スケジュール、費用対効果などの観点から検討した結果、下記の対応を決定をしました。

【既存システムへの手直し】

見直し後のシステム構成基準の実装
アカウント管理機能の強化

【新規に導入・構築】　※製品名の紹介は控えさせていただきます。

暗号化システムの導入
アンチウイルスシステムの導入
アクセス管理システムの導入
ログ管理システムの導入
ファイル整合性監視システムの導入

（6）実行計画

対策立案がまとまったところで、以降のフェーズ（対策実行、認定審査）での具体的な対応事項、スケジュールとコストプランなどを明記した実行計画を策定・上申し、承認を得ることができました。

次回は、いよいよプロジェクトの山場となる次フェーズ「対策実行フェーズ」のご紹介となります。

（次回へ続く）

PCI DSS認定取得への道！

本コラムでは、弊社でのPCI DSS認定取得に際して、実際に取得プロジェクトに携わったエクサメンバーによる『担当者ならではの視点』から、大変だった点、上手くいったコツ、失敗しがちなポイントなどをご紹介いたします。これからPCI DSS認定取得を計画されている企業様、特にどのように進めれば良いかを模索されている企業様のご参考になれば幸いです。

エクサは、クレジット事業者向けWebクラウドサービス「BLUEBIRD」において、2014年に「PCI DSS Ver2.0」の認定（2016年PCI DSS Ver3.1で更新認定）を取得しました。

また、「BLUEBIRD」のWebシステム基盤である「PCI DSS準拠IaaSサービス：TRINOS」は、クレジット業界の利用者のみならず、幅広い企業にセキュアな環境と運用サービスを、スピーディーかつ低コストで提供しています。