PCI DSSがV3.1に改訂(正式リリース前) | PCI DSS Ready Cloud

2015.03.06

PCI DSSがV3.1に改訂(正式リリース前)

  • このエントリーをはてなブックマークに追加
本ブログは、PCI DSS Ver3.1改訂に関する正式発表の前に作成したVer3.1へのアップデートに変更が予想される要件と
その内容に関する記事です。

2015年4月15日に正式リリースされたPCI DSS Ver3.1の変更点については、最新記事を参照してください。
(2015/6/2追記)

2016年4月28日に正式リリースされたPCI DSS Ver3.2の変更点については、最新記事を参照してください。
(2016/5/18追記)

PCI DSS Ver3.1改訂の理由

2015年2月15日にPCI DSSとPCI PA-DSSについて現行のバージョン3.0から3.1にレビジョンアップ(比較的小規模な改定・修正)する予定であることが、PCI DSSを発行するPCIセキュリティ審議会(PCI SSC)からアナウンスされた。きっかけは「Poodle」問題である。
ご存知の通り2014年10月14日(米国時間)にSSL v3.0に関する脆弱性(CVE-2014-3566) が公開され、同プロトコルを使用している場合に、本来暗号化されているはずの通信が解読され、情報が第三者に漏えいするリスクがある。 PCI DSSでは、要件1.1.6、要件2.2.3、要件2.3、要件4.1など複数の要件でSSL v3.0を安全なプロトコルとして取り扱っており、その点についての修正がなされると予測される。2015年2月からの数ヶ月の間にPCI DSS及びPA-DSSのバージョン3.1がリリースされるとPCI SSCはアナウンスしている。なお予想される変更の詳細を末尾の表に記しているので参照いただきたい。

現行のバージョン3.0は、2013年10月にリリースされ、2014年1月に使用開始された。使用から1年数ヶ月を経過して使用するバージョンが変わることになる。
実はPCI DSSのレビジョンが、バージョンアップ期限前にこのレベルで改訂されるのは、初めてのことである。(過去にも誤字の変更などのレベルはあったがV1.2.1程度のレビジョンアップであった。)このため新バージョン3.1への移行措置についても同時にアナウンスされることになると推測される。

準拠企業では続々とSSLからTLSへ

なお、新バージョンが発行されるまで準拠企業がこれらの対応をしていないかというとそんなことはない。PCI DSSの要件11.2で要求される四半期に一度ASVの外部スキャンでは、SSLを使用して外部にサーバを公開している場合、検査結果を不合格(Fail)としているケースが多い。

ASVからのFailの結果は、年に1回監査を実施するQSAがこの項目の準拠を認めないため、既に準拠企業の間ではSSLの通信を閉じ、TLSへの移行が進んでいる。

バージョンアップのサイクルについての懸念

PCI DSSの現状の定期バージョンアップサイクルは3年間に1度であり、移行期間含めると最長4年間の使用が可能である。このサイクルが、ISOなどの規格のバージョンアップ頻度と比較して早いと感じる方も多い。

しかし昨今の攻撃手法の進化のスピードを鑑みると3年間でも長いのではないかという懸念があるのも事実である。よって米国では、PCI DSSはカード会員データを保護するための最低限の基準であり、追加の管理策を実施しなければ自社を守れないという考え方が一般的になりつつあるという。
PCI DSSも「Poodle」レベルの脆弱性が発見された場合には、これを前例にレビジョンアップがなされていくことが予想される。
▽Ver3.1へのアップデートに変更が予想される要件とその内容
要件番号 Ver3.0の要件 Ver3.1において予想される変更点
1.1.6.a ファイアウォール/ルーター構成基準に、業務における必要性を含む、すべてのサービス、プロトコル、ポートを文書化したリストが含まれていることを確認する(HTTP(ハイパーテキストプロトコル)、SSL(セキュアソケットレイヤ)、SSH(セキュアシェル)、VPN(仮想プライベートネットワーク)プロトコルなど)。 “SSL(セキュアソケットレイヤ)”の記述が”TLS(トランスポートソケットレイヤ)”に
変更されると予想される。
2.2.3 安全でないとみなされている必要なサービス、プロトコル、またはデーモンにセキュリティ機能を実装する(たとえば、SSH、S-FTP、SSL、またはIPSec VPN などの安全なテクノロジを使用して、NetBIOS、ファイル共有、Telnet、FTP などの安全性の低いサービスを保護する “SSL”の記述が”TLS”に変更されると予想される。
2.3 強力な暗号化を使用して、すべてのコンソール以外の管理アクセスを暗号化する。Webベースの管理など非コンソール管理アクセスについては、SSH、VPN、またはSSL/TLSなどのテクノロジを使用します。 “SSL”の記述が削除されると予想される。
4.1 オープンな公共ネットワーク経由で機密性の高いカード会員データを伝送する場合、以下のような、強力な暗号化とセキュリティプロトコル(SSL/TLS、IPSEC、SSH など)を使用して保護する。
  1. 信頼できるキーと証明書のみを受け入れる
  2. 使用されているプロトコルが、安全なバージョンまたは構成のみをサポートしている
  3. 暗号化の強度が使用中の暗号化方式に適している
オープンな公共ネットワークの例として以下が挙げられるが、これらに限定されない。
  1. インターネット802.11 とBluetooth(ブルートゥース)を含むワイヤレステクノロジ
  2. Global System for Mobile communications(GSM) や Code division multiple access(CDMA)などの携帯端末テクノロジ
  3. General Packet Radio Service(GPRS)
  4. 衛星通信
“SSL”の記述が削除されると予想される。
PCI DSS Ready Cloudでは、PCI DSS v4.0への効率的な移行支援及び準拠を促進するクラウドサービスを提供しています。
是非一度、ご相談ください。
PCI DSS準拠を促進するクラウドサービスならPCI DSS Ready Cloud

■ PCI DSS の構築、維持・運用にかかるコストと工数を削減する
PCI DSS Ready Cloud マネージドモデルはこちら
 
■ AWSでの開発事業者や外部ベンダー/事業者との専用線接続がない場合に最適
PCI DSS Ready Cloud AWSモデルはこちら
 
■ 国内トップクラスのPCI DSS専門のコンサルタント集団によるPCI DSS準拠支援サービス
PCI DSS準拠支援コンサルティングはこちら
 
【関連記事】
PCI DSSとは?準拠が必要な企業とセキュリティ対策をガイダンス
【動画付き】PCI DSS バージョン4.0の特徴や変更点を解説

この記事が気に入ったら
いいね!しよう

PCI DSS 関連の最新記事をお届けします

  • このエントリーをはてなブックマークに追加