BLOG

クレジットカード業界やPCI DSSに関する最新動向をお届けします

2019.06.06

PCI DSS バージョン4.0に向けたPCI SSCの検討状況

  • このエントリーをはてなブックマークに追加
■ AWSで実現したPCI DSS準拠 : 1ヵ月でシステム構築。低コストで、スピード感あるローンチに成功した事例

PCIデータセキュリティ基準バージョン4.0(以下PCI DSS v4.0)は、2020年後半以降の公開が予定されている。現行バージョンのv3.2.1からの改訂が検討されているポイントについて、PCI DSSを発行管理するPCI Security Standard Council(以下PCI SSC)の発表記事をもとに紹介する。なお改訂内容は、今後の関係者からのPCI SSCへのフィードバックによって変更になる場合があることに留意いただきたい。

 

業界標準への対応やセキュリティ強化を検討

PCI SSCは、PCI DSS v4.0に向けた改訂を進めるために、2017年9月から11月をRFC(Request for Comment)期間として、関係者からのフィードバックを募った。PCI DSSを構成する12要件についてはバージョン4.0でも基本的に変更されることはないが、いくつかのポイントについて改訂が検討されている。

1)ユーザーアカウント要件にNIST(アメリカ国立標準技術研究所)の新しいパスワードガイダンスや多要素認証の条件に関する記載を反映


2017年6月、NIST SP 800-63(Digital Identity Guidelines)が改訂された。NIST SP 800シリーズは米国の政府機関の情報セキュリティ基準であり、PCI DSSではいくつかの要件でNIST SP800シリーズを業界標準として引用している。そのため、NIST SP 800-63B[日本語版]に記載された以下のような内容をパスワードや多要素認証に関する要件に反映することが想定される。


〇要件8.2.3(パスワードの長さや文字種類)および要件8.2.4(パスワードの定期変更)に関する変更や追加
従来のNIST 800-63Bでは、パスワード保護のセキュリティレベルを保つため、英字、数字、記号の混在や定期的な変更など、さまざまな要件を課していた。しかし、過去に漏えいしたパスワードデータベースの分析から、複雑な要件を課してもパスワードの脆弱性は改善されないことが明らかになったという(詳細はNIST 800-63Bの付録Aに記載されている)。

これを受けて、以下のような方針の改訂と、その考え方が示されている。

  • ・パスワードはランダムに決定する場合6文字、ユーザが決定する場合は8文字以上で、それ以上複雑な要件は求めないこと。一見、パスワード保護のセキュリティレベルが下がっているように見受けられる。しかし、必要以上に複雑なパスワード要件を課したとしても、人間の記憶力には限りがあり、複数の複雑なパスワードを記憶することは困難である。そのため、ユーザは他のシステムで使用しているパスワードを使いまわしたり、パスワード忘れを防ぐためにメモを残したりする。これではかえって脆弱性が増すことになり、逆効果であるとしている。

  • ・定期的変更は求めないこと。定期的なパスワード変更を強制されると、ユーザの多くは以前のパスワードの末尾に数字を追加するなど単純なルールで新たなパスワードを作成する場合が多い。容易に推測可能であり、セキュリティ強化の観点では意味がない。

  • ・パスワード設定時にユーザが安全なパスワードを設定できる仕組み(連続した文字列や辞書に含まれる単語など不適切な文字列を受け付けない、パスワード強度メーターによるガイダンスなど)を実装すること。既に多くのサイトやサービスから、ユーザIDとパスワードが漏えいしており、データベース化されている。過度に複雑な条件を加えたり、定期的な変更を強制したりすることは、既に漏えい済みのパスワードが利用される脆弱性につながる。推測されにくい安全なパスワードをユーザに使わせるためには、ブラックリスト方式による単純なパスワードの排除や、認証画面におけるパスワード入力試行回数に制限を設けるなどの制約をシステム側で実装する方が実効性が高い。


〇要件8.2 多要素認証の際のSMSまたは音声通話によるパスワードの通知
NIST SP-800-63では、ショートメッセージもしくは音声通話による認証を「所有による認証」として位置付ける。これは、事前登録済みの電話番号が特定の物理デバイスに結び付けられていることを前提としているからである。

しかし、昨今のスマートフォンや携帯電話はSIMカード入れ替えやナンバーポータビリティにより電話番号を異なるデバイスで利用可能だ。逆に、1台のスマートフォンに複数のSIMカードを入れ替えて利用すれば、複数の電話番号宛のショートメッセージを受信することが可能になる。もはや、電話番号と物理デバイスが1対1に対応するという、そもそもの前提が崩れてきている。

そのため、NISTはショートメッセージや音声通話を多要素認証の通知手段として用いる場合は、将来十分なセキュリティが担保できなくなる可能性を考慮して、別の認証手段への移行プランを立てておくことなどを推奨している。

 

2)暗号化通信の適用範囲を拡大

PCI DSSは、店舗と本部間の専用線やデータセンター内などの内部ネットワークでは、カード会員データを平文で送受信することを許している。しかし、すでに大半のPCI DSSの準拠組織は、専用線から決済ネットワークへカード会員データを送信する際、暗号化して通信している。また内部にマルウェアが侵入した場合は、内部ネットワークでカード会員データを傍受し、外部に送信することが可能である。

そのため、現在は要件4.1でオープンな公共ネットワークを利用してカード会員データを伝送する場合のみ一定以上の強度で要求している暗号化を、外部の組織や内部ネットワークの通信でも求めることが予想される。


3)技術の進歩を考慮したモニタリング要件

いくつかのPCI DSS要件は、外部の基準を引用している。例えば要件6.5ではアプリケーションの開発コードレビューを要求しており、その項目は業界のベストプラクティスであるOpen Web Application Security Project(OWASP)が選定した脆弱性に対応している。同時に、要件6.5には、引用している基準がバージョンアップした場合はそちらを優先することが記載されている。要件6.5以外にも、NIST、SANS、ISOなどを引用している要件もある。そのため、それらの関連基準やガイドラインに対する継続的なモニタリングプロセスが求められると予想される。
このプロセスでは、暗号強度やTLSのバージョンなども対象になる可能性がある。過去には、SSL/TLS1.0の脆弱性が発見された際、PCI DSSは緊急でバージョンアップした経緯がある。また2030年までにNISTは112bit強度の暗号を128bit以上のものに移行することを求めている。PCI DSSの要件中に推奨する技術として記載があったとしても脆弱性が見つかった、危殆化が予定されている基準を、準拠組織自身でモニタリングし、移行するプロセスが求められるだろう。



4)重要なコントロールに対するテスト頻度の増加

PCI DSS v3.2のバージョンアップの際に、国際ブランドが指定した事業体向けの要件として追加された付録A3の要件のうち、いくつかを通常のPCI DSS要件に組み込むことが検討されている。

現状では付録A3は、国際ブランドが指定したカード会員データを大量に扱う事業者や、カード会員データの重大な侵害を受けたことがある事業者に追加で適用される要件である。その一部を一般の事業体にも適用することで、PCI DSS準拠組織がセキュリティレベルを自身でレビューして維持向上するプロセスを導入することが予想される。例えば、組織が使用しているハードウェアおよびソフトウェアテクノロジーの年1回のレビュー(要件A3.3.2)、ユーザーアカウントとアクセス権限の半年毎のレビュー(要件A3.4.1)などが該当すると思われる。

 

バージョン4.0のリリースは2020年後半以降

PCI SSCは今後さらに追加のRFC期間を設けるとしている。寄せられたフィードバックを反映した上で、PCI DSS v4.0がリリースされる。バージョンアップの主な目標として、以下の4点が挙げられている。

  • ・ペイメント業界のセキュリティニーズを満たしていること
  • ・セキュリティを向上するために柔軟性と新しい手法への対応を追加すること
  • ・継続的なプロセスによりセキュリティを促進すること
  • ・各要件の検証方法と手順をさらに改良すること

冒頭にも述べた通り、リリース時期については早くとも2020年後半以降であり、具体的な時期については2019年5月末の時点で明らかにされていない。前述の追加や変更の内容やリリース時期も今後のフィードバックによって変更となる可能性がある。

(著:fjコンサルティング(株)代表取締役CEO 瀬田 陽介)

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

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

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