現在地

PCI の新たなソフトウェアセキュリティ基準 Software Security Framework - その1:Framework の概要

2019年1月、PCI SSCより新たなソフトウェアセキュリティ基準、PCI Secure Software StandardとPCI Secure Software Lifecycle (Secure SLC) Standardがリリースされました[1]。これら二つの基準はPCI Software Security Frameworkを構成する基準群と位置づけられており、Frameworkはこれら二つの基準に加えて、ソフトウェアや審査員の認定・登録プログラムから構成されます。本コラムでは、PA-DSS(現行のPCI決済アプリケーションセキュリティ基準)の後継となるこのFrameworkについて、3回に分けて紹介します。1回目となる本稿では、Frameworkの全体像について紹介します。2回目にSecure Software Standard、3回目にSecure Software Lifecycle Standardを紹介する予定です。

PA-DSSと「実行計画」

Software Security Frameworkの話に入る前に、まずPA-DSSについて簡単に解説します。
PA-DSSは、Payment Application Data Security Standard(決済アプリケーションデータセキュリティ基準)の略で、パッケージやライセンスなどの形式で配布・販売されるPOSなどの決済アプリケーションを、PCI DSS審査の中で評価できるようにするための基準として策定されました。
例として、PCI DSSのスコープ内にPOSが存在しているケースを考えます(図1)。このPOSアプリをPCI DSS審査で評価しようとした場合、開発ベンダーでないと分からない様々な情報―開発ポリシー・プロセス文書、レビュー記録、テスト記録、開発者のトレーニング記録等々―が必要になりますが、通常、POSベンダーにそのような詳細情報を開示してもらうことは難しく、加盟店やQSAから見て、POSアプリはブラックボックスとなります。このような場合に、POSベンダーがPOSアプリのPA-DSS認定を取得していれば、PCI DSSの審査においては、アプリケーションそのものや開発プロセスなどの評価はPA-DSS認定によって満たしていると見なせます。従ってQSAは、アプリケーションが環境内に適切に導入・設定されているか、PCIの要件に従って運用されているかといった点について評価をすることで、ブラックボックスのPOSアプリがある環境でもPCI DSSの審査を実施することが可能となります。

図1

図1

一方、日本国内におけるクレジットカード情報の保護については、「クレジットカード取引におけるセキュリティ対策の強化に向けた実行計画」、通称「実行計画」に従って進められています[2]。実行計画において対面加盟店が取り得る対策としては大きく分けて、非保持化(外回り方式)、非保持と同等/相当(内回り方式)、およびPCI DSS準拠の三つがあります(図2)。これらのうち、内回り方式の対策にはP2PEソリューションの導入、もしくは技術要件11項目の実装の二つがありますが、後者の技術要件11項目の中の一つにPA-DSSに準拠したPOSアプリケーションの利用があります*i。このことから、国内においてはPCI DSSに準拠しない場合であってもPA-DSS認定アプリが利用されるケースが想定されます。

図2

図2

Software Security Frameworkと他のPCI基準との関係

Secure Software StandardおよびSecure SLC Standardと合わせて公開された文書としてFAQ[3]があります。このQ14-16に他のPCI基準との関係についての項目があるので、ここで紹介します。
まずQ14にPA-DSSとの関係についての項目があります。Q14の回答では、FrameworkとPA-DSSは分離・独立した別の基準であることを前提とした上で、最終的にはPA-DSSは段階的にFrameworkに移行・統合されることが述べられています。また既存のPA-DSS認定アプリケーションは、当該PA-DSSバージョンの失効日まで(年次更新等の必要な手続きをした上で)その認定は継続されます。失効日以降も認定を継続したい場合、例えばPA-DSS v3.2認定アプリの場合は失効日が2022年10月末のため、それまでにSecure Software Standardによる認定を受ける必要があります。認定を受けない場合は、失効日を過ぎると「既存の導入済のみ認められる」(“Only Acceptable for Pre-Existing Deployments”)の状態になります。
次のQ15はPCI DSSとの関係についての項目です。これについてはPA-DSSとPCI DSSとの関係と同様に考えれば良いでしょう。すなわちFramework準拠ソフトウェアの利用はPCI DSS準拠を支援するかもしれないが、利用することが直ちにPCI DSS準拠を意味することにはならず、適切に設定されPCI DSS要件を満たすことを示さなければならない、といったことが述べられています。
最後のQ16がPCI DSS、PA-DSS以外のPCI基準との関係についてです。2019年4月現在、Software Security Frameworkに含まれるセキュリティ基準は2つだけですが、将来的に他のPCI基準の要素(element)がFrameworkに統合されるかもしれない、といった内容が述べられています。そこで表1に、主にソフトウェアに関係するPCI基準をまとめてみました。

基準概要
PCI DSS ・Payment Card Industry Data Security Standard
・クレジットカード情報を扱う全ての事業体を対象とした、カード情報保護を目的とするセキュリティ基準
PA-DSS ・Payment Application Data Security Standard
・PCI DSS 対象の環境内で利用される決済アプリケーションを対象とするセキュリティ基準
・パッケージ・ライセンス販売等で配布されるアプリケーションが対象(受託開発等の特定一社向けは対象外)
P2PE ・Point to Point Encryption
・カード情報の保護を高めるための2拠点間の暗号化ソリューションを対象とするセキュリティ基準
SPoC ・Software-Based PIN Entry on COTS (Commercial Off-The-Shelf、市販品・民生品のこと)
・加盟店で利用される、スマートフォンやタブレット(COTSデバイス)上で動作する PIN 入力を伴うモバイル決済ソリューションを対象とするセキュリティ基準
PCI Software
Security Framework
・PA-DSS の後継として新たに策定された決済ソフトウェアに関するセキュリティ基準
・PA-DSSより広範囲の、より新しいテクノロジを用いたソフトウェアも対象に含まれる

表1 PCI DSSと主にソフトウェアに関係するPCI基準

いずれにしても、統合される場合は十分事前に告知されることが述べられています。

PCI Software Security Framework の概要

さて、ここからはSoftware Security Frameworkの概要を見ていきましょう。
最初にSoftware Security Framework の特徴をまとめました。

  • 複数の基準で構成される(2019年1月のリリース時点では2つの基準)
  • PA-DSSより広い範囲のソフトウェアが適用対象となる(SaaSやモバイルアプリなど)
  • Agile/DevOpsのような新しい開発手法も考慮
  • Objective-based Approachの採用

以下、これらの特徴を順番に紹介していきます。

なお、本稿執筆時点(2019年5月)において、Framework関連文書として正式版がリリースされているのは二つの基準書(Secure Software Standard, Secure SLC Standard)およびFAQのみとなっており、プログラムガイドはリリースされていません。こちらについては2019年6月にリリース予定とアナウンスされており[4]、プログラムガイドで定められるであろう事項―例えば、評価を実施するPCI SSC認定審査員(assessor)の資格認定制度や、PA-DSSからの移行を含む決済ソフトウェアの認定プロセスなど―は、未定となっています。これらの内容については、本コラムの「その2」以降で紹介したいと思います。

複数の基準で構成される

2019年1月のリリース時点において、Software Security Frameworkは表2に示す二つの基準で構成されています。

基準認定対象備考
PCI Secure Software Standard決済ソフトウェア 
PCI Secure Software Lifecycle (Secure SLC) Standard開発ベンダー取得は任意

表2 Software Security Frameworkに含まれる基準

まずSecure Software Standardは認定対象が決済ソフトウェアであることから、PA-DSSの直接の後継であると考えられます。
一方Secure SLC Standardは、認定対象が開発ベンダーで、取得はオプションとなっています。これは、Secure SLC認定を取得した開発ベンダーは未認定の開発ベンダーと比べて、自己検証が可能となるソフトウェア変更の範囲が広くなるという違いがあるようです。どの程度の変更までが自己検証可能となるかの詳細についてはプログラムガイドで定められると思われますので、「その2」以降で紹介する予定です。
なおPA-DSSでは「決済アプリケーション(Payment Application)」と呼んでいましたが、Frameworkでは「決済ソフトウェア(Payment Software)」という呼び方で統一されるようです。

PA-DSSより広い範囲のソフトウェアが適用対象となる

PA-DSSは2008年に策定されていますが、PCI DSS の環境に導入されるPOSのような昔ながらの決済アプリケーションを対象にデザインされているため、適用対象が限られています。特にSaaSやモバイルアプリに適用できないため、これらのアプリケーションにも適用できる現代的なソフトウェアセキュリティ基準への改訂が望まれていました。このような事情を背景として、より広い範囲のソフトウェアに適用できる基準として新たに策定されたのがSoftware Security Frameworkということになります。
具体的にどのようなソフトウェアが対象となるかについての詳細については、プログラムガイドで定義されると思われます。

Agile/DevOpsのような新しい開発手法も考慮

先ほど、Secure SLC認定を取得した開発ベンダーは、自己検証が可能となる範囲が広くなることを述べました。これはAgileやDevOpsのような開発プロセスに対応することが想定されています。つまり、頻繁な更新をするたびにPCI SSC認定審査員による評価を受けなくてはいけないのではAgile/DevOpsといったプラクティスが回らなくなってしまうので、自己検証できる範囲をより広くしたということであると思われます。逆に言えば、そのようなプラクティスを採用している開発ベンダーでなければ取得するメリットも小さくなるので、オプション扱いとしているのでしょう。

Objective-based Approach

Software Security Frameworkでは、PCI DSSやPA-DSSの要件(Requirement)に相当する項目が、コントロール目標(Control Objective)と呼ばれる項目に変更されました。これは、Objective-based Approachの導入に伴った変更と考えられます。Objective-based Approach を和訳するのは難しいですが、直訳すれば「目標に基づいたアプローチ」でしょうか。基準書の説明には、以下のようなスローガン(?)が記載されています。

There is no “one size fits all” method to software security.
(全てに対応できる万能のソフトウェアセキュリティ手法はない)

この考え方に基づいてSecure Software StandardおよびSecure SLC Standardのコントロール目標では、PCI DSSやPA-DSSの要件とは大きく異なり、具体的なレベル、厳密性、頻度などが一部を除いて定められていません。これらを決定するにあたって、ベンダーは強固な(robust)リスク管理プロセスを保持し、そのリスク評価の結果を根拠とすること、またその決定について説明できることが求められています。いくつかのコントロール目標やそのガイダンスではNIST SP800などの参照文書が挙げられているので、セキュリティコントロールが十分リスクを低減していることを示すのに、これらの業界標準となっている文書を根拠とすることが考えられるかもしれません。
なお、具体的なレベルが定められたコントロール目標の例としては、Secure Software Standardのコントロール目標7.2で暗号鍵のビット強度として少なくとも128 ビット以上、コントロール目標7.3で乱数生成器の生成する乱数のエントロピーとして少なくとも128 bit以上が求められています。またSecure SLC Standardのコントロール目標1.1、1.3、2.1、2.3、8.3で、少なくとも年次でのレビューを実施することが求められている文書等があります。

まとめ

PA-DSSの後継となる、PCI SSCの新たなソフトウェアセキュリティ基準PCI Software Security Frameworkについて、概要を紹介しました。現時点ではプログラムガイドがリリースされていないため、適用対象となる具体的なソフトウェアや、PA-DSSからの移行などの詳細は未定ですが、2019年6月にリリース予定とアナウンスされているので、本コラムの「その2」以降で紹介したいと思います。「その2」では、Frameworkを構成する二つの基準の内の一つ、Secure Software Standard について紹介する予定です。

  • *i: 正確には、技術要件11項目の中の1項目で、DUKPTによるトラックデータの暗号化、もしくはPA-DSS準拠のPOSアプリケーションの利用のいずれかが求められています。

Writer Profile

セキュリティ事業部
セキュリティコンサルティング担当 チーフコンサルタント
佐藤 功視(CISSP、CISA、QSA、PA-QSA、博士(理学))

参考文献