カードセキュリティ最新情報, カードセキュリティPCI DSS, トップページ用注目ニュース, ペイメントニュース, ペイメント新着情報

PCI SSC の最新ソフトウェアセキュリティ基準の概要（アップデート版）

2020年12月10日8:30

【PR】NTTデータ先端技術株式会社/タレスDIS CPLジャパン株式会社

2019年1月にPCI SSCより、PA-DSSの後継となる新たなソフトウェアセキュリティ基準として、Software Security Framework (SSF) がリリースされた。2019年3月の本フォーラムでSSFについて紹介したが（関連記事をリンク）、その後にリリースされたプログラムガイドや、PA-DSS からの移行についてのアナウンスなどの内容を加え、SSFについて解説。SSFは、国内においてはクレジットカード・セキュリティガイドラインにおける「非保持と同等相当」でも参照されているPA-DSSの後継としても注目されている。また、NTTデータ先端技術が取り扱っているThales（タレス）社製の暗号化、トークナイゼーション等、PCI DSSの準拠維持をサポートするソリューションを紹介する。

●NTTデータ先端技術株式会社セキュリティ事業本部セキュリティコンサルティング事業部コンサルティングサービス担当チーフコンサルタント佐藤功視（さとうのりあき）氏 (QSA, PA-QSA, QSA(P2PE), PA-QSA(P2PE))

PA-DSSの後継として注目されるSoftware Security Framework（SSF）

今回の主題は、2019年1月にPCI SSCよりリリースされたPA-DSSの後継となるソフトウェアセキュリティ基準、Software Security Framework（SSF）です。その認定プログラム（Secure Software Standardプログラム、Secure SLC Standardプログラム）を中心にお話しさせていただければと思います。

NTTデータ先端技術株式会社セキュリティ事業本部セキュリティコンサルティング事業部コンサルティングサービス担当チーフコンサルタント佐藤功視氏

まず、クレジットカード・セキュリティガイドラインとPA-DSSの関係についてご説明します。2018年6月に施行された改正割賦販売法では、実行計画の実施期限が2020年3月まででした。この後継となるクレジットカード・セキュリティガイドラインのバージョン1が、2020年3月にリリースされました。この内容は実行計画とそれほど大きく変わっていません。対面加盟店には、PCI DSS準拠、外回り方式による非保持化、あるいは、内回り方式による非保持同等/相当の対応が求められています。内回り方式には大きく分けて、P2PEソリューションか技術要件11項目の導入があり、技術要件11項目をクリアする方法として、DUKPT暗号化、もしくは、PA-DSS準拠のPOSアプリケーションが求められています。

これがSSFにどうつながるかを解説します。現状最新のPA-DSSバージョン3.2は2022年10月28日でプログラムが終了となります。それ以降はすべてのPA-DSS認定アプリケーションが「既存の導入済みのみ認められる」ステータスとなります。これは、新規の導入が認められなくなることを意味します。

これに合わせて後継基準として策定されたのがPCI SSFです。認定プログラムはすでに開始されておりPA-DSSの終了までは、PA-DSSとSSFの平行期間になります。

PA-DSSの審査員資格であるPA-QSAは、P2PE アプリケーションの審査員資格であるPA-QSA（P2PE）取得の前提資格になっています。これについてもSSFへの移行にともなって何らかの変更があることが推測できますが、現時点ではSSCからのアナウンスはされておりません。

一方国内事情としては、クレジットカード・セキュリティガイドラインのバージョン1が2020年3月に公開されましたが、そこではまだ特にPA-DSSの終息については触れられていません。2022年10月の終息までには何らかの更改がされることが期待されます。

ソフトウェアと開発ベンダを対象とした2つの基準から構成

次に、PCI SSFの概要についてご説明いたします。策定の背景には、PA-DSSの策定が2008年とかなり古いことがあります。新しい開発手法や技術を利用した決済アプリケーションに対応するために定められたのがPCI SSFです。

フレームワークの特徴は、2つの基準で構成されていることです。その1つはPCI Secure Software Standardで、ソフトウェアを認定対象としており、PA-DSSの直接の後継となるものです。公式な略称はないのですが、長いので本記事中ではSSSと略記する場合があります。もう1つはPCI Secure Software Lifecycle（Secure SLC）Standardで、認定対象は開発ベンダですが、取得は任意となっています。

いずれの基準も認定を受けるとPCI SSCのウェブサイトに掲載されます。2020年11月10日時点でSecure SLC認定を受けたベンダが１つ、SSS認定を受けたソフトウェアはないようです。

ほかの特徴として、Objective-based Approachが挙げられます。PCI DSSやPA-DSSでは要件と呼んでいたものが、SSFではコントロール目標（Control Objectives）と呼ばれています。「すべてに対応できる万能のソフトウェアセキュリティ手法はない」という認識から、SSFのコントロール目標では、特定のレベル、厳密さ、頻度などはほぼ定められておりません。

それではどこまでやればいいのかというと、ベンダが強固なリスクマネジメントプロセスを定めて、BAUの一部として保持することが求められており、その中でベンダ自身が決定するということになります。審査にあたって、ベンダは、自分たちが定めたベースラインが有効で、求められている要件を満たしていることを、審査員に示す必要があります。

次に、PCI SSFとほかのPCI基準との関係についてご説明します。まずPA-DSSとの関係については、両者は分離・独立した基準ですが、最終的にはPA-DSSプログラムはSSFにマージされ移行していくことになります。PCI DSSとの関係についても、独立した基準ということになります。

その他のPCI基準との関係についても、現状では独立した基準という立て付けになっていますが、将来的には、ソフトウェアに関する基準の一部がPCI SSFに統合される可能性があることがアナウンスされています。

国内では、P2PEのアプリケーションを対象とするドメイン2がSSFに統合された場合にインパクトが大きいと考えています。P2PEを利用している加盟店や、P2PEのソリューションやアプリケーションを提供しているベンダは、今後の動きを注視しておく必要があるかもしれません。

これを裏付ける状況証拠の1つとして、Terminal Software Moduleというものがアナウンスされています。2020年5月1日から6月22日の間にRequest for Comments（RFC）が実施されました。これは決済端末上で動作する決済ソフトウェアを対象とするモジュールです。このモジュールを含むSecure Software Standardのバージョン1.1が2020年下期にリリース予定となっています。

決済端末上で動作する決済ソフトウェアを対象としているということは、P2PEアプリケーションはこの括りに含まれることになるので、P2PEのドメイン2（P2PEアプリケーションを対象とするドメイン）をPCI SSFに統合するための準備としてTerminal Software Moduleを策定しているのではないかと、個人的には考えています。

Secure Software Standardの認定プログラム

それでは、PCI SSFの認定プログラムについて説明します。Secure Software Standard、Secure SLC Standardの認定プログラムを定めた、プログラムガイドという文書があります。

先に、Secure Software Standardのプレイヤーとその役割についてご紹介します。PCI SSCがSSA（Secure Software Assessor（審査員））の資格認定をします。認定されたSSAが、ベンダが開発したソフトウェアの審査を行って、レポート(ROV, Report of Validation)を作成します。レポートはSSA経由でPCI SSCに提出され、レビューのプロセスに進みます。そこで合格すると、ソフトウェアは晴れて認定を受け、PCI SSCのウェブサイトに掲載されます。

次に認定の維持のプロセスについてご説明します。ソフトウェアの変更がない場合は、毎年、年次検証を継続することで、3年間認定を維持することができます。検証方法は自己検証でよいのですが、検証した結果(AOV, Attestation of Validation)をPCI SSCに提出して、レビューを受けて、承認されれば、認定が継続されます。ただし年次検証が期日までに提出されなかった場合には、その時点で認定が終了になってしまいます。

次に、ソフトウェアの変更がある場合のSecure Software Standard認定の維持について説明します。変更がある場合にはまず、変更の種別を評価する必要があります。変更種別には、High Impact（影響大）、Low Impact（影響小）、Administrative（管理）の3種があります。PA-DSSの場合には、No Impact（セキュリティに影響なし）という種別があったのですが、それがなくなっています。これはソフトウェアに何らかの変更があった場合には、必ず申請が必要になることを意味します。

それぞれの変更種別に対して、検証方法が定められています。その方法は、ベンダがSecure SLCの認定を受けているかいないかで異なってきます。

まずベンダがSecure SLCの認定を受けていない場合です。最初の検証/フル検証は3年ごとに必要です。High Impact（影響大）の場合もフル検証が必要です。年次検証とAdministrativeについては、自己検証を行っていただきます。Administrativeは、会社名が変わったとか、アプリケーションの名称を変えたいといった、アプリケーションの中身自体は変わらない変更です。Low Impact（影響小）の場合は、差分検証が必要になります。検証方法としては、ベンダの差分レビューによる自己評価に加えて、SSAによる評価を必ず受けなくてはなりません。つまり、ベンダがSecure SLCの認定を受けていない場合は、ソフトウェアに変更があるときは、必ずSSAによる評価が必須になるというところが大きなポイントです。

一方、ベンダがSecure SLCの認定を受けている場合は、Low Impactならば自己検証のみで済みます。頻繁にバージョンアップするようなベンダであれば、Secure SLC認定を受けることが大きなメリットになります。

ただし、Secure SLC認定を受けるのは対応の難易度、コストの両面からそれほど簡単ではないと思われます。アップデートの頻度がどれぐらいなのかということが、一つの判断材料になるのだろうと思います。

最後にSecure Software Standardの適用対象について説明します。PA-DSSの対象である商用Off the Shelf（COTS）や決済モジュールなどは、引き続きSecure Software Standardの対象に含まれます。PAの対象ではないがSecure Software Standardの対象となるソフトウェアの例としては、SaaSや、決済ソフトウェアと統合されているOSやDBが挙げられます。

ただし、これらの適用対象はあくまでSSS バージョン1.0におけるものであることに注意が必要です。将来的に対象が拡張される可能性についてはバージョン1.0リリース時からアナウンスされていました。実際、PTS POIデバイスなどのハードウェア端末上で動作する決済ソフトウェアは、バージョン1.0では対象となっていませんが、先ほどご紹介したTerminal Software Moduleの対象となるので、Terminal Software Moduleが含まれるバージョン1.1では対象に含まれることになると思われます。

Secure SLCの認定プログラム

次にSecure SLCプログラムの認定プログラムについて説明します。まずプレイヤーとその役割についてですが、SSSと大きく変わるところはありません。PCI SSCから認定を受けたSSLCA（Secure SLC Assessor（審査員））がベンダの審査を行って、レポート(Report on Compliance)を作成し、それをPCI SSCに提出してレビューに通れば、認定ベンダとしてPCI SSCのウェブサイトに掲載されます。

年次検証についてもSSSとほぼ同じですが、少し条件が緩和されており、提出期日を過ぎても14日以内は猶予されることになっています。14日を過ぎても90日以内であれば警告状態のオレンジ表示にとどまり、この期間に自己評価を報告すれば黒表示に戻って、1年間認定を継続することができます。90日を過ぎると赤表示になり、認定を受けるにはフル審査が必要になります。

変更がある場合のSecure SLC認定の維持についてご説明します。Secure SLCの変更種別にはDesignated（指定）とAdministrative（管理）の2つが定められています。

変更種別ごとの検証方法ですが、最初の検証と3年ごとのフル検証についてはSSLCA会社による評価が必要ですが、年次検証、およびDesignated/Administrative変更発生時の検証は自己検証になっています。

それ以外の変更についてですが、プログラムガイドに掲載されているフローチャート（バージョン1.0, Figure 3）を見ると、変更がAdministrative（管理）でもLow Impact（影響小）でもない場合にはフル審査が必要とされています。ところがLow Impact（影響小）という編国種別はSecure SLCでは定義されていません。そこでSSCのプログラムマネージャーに確認したところ、この図のLow Impactは、Designatedの誤りだろうということでした。早晩プログラムガイドが修正されることが期待されます。

まとめると、DesignatedでもAdministrativeでもない変更の場合は、フル審査が必要ということになります。

PA-DSSと比較して難易度の高いコントロール目標を設定

Secure Software Standardの概要についてご紹介します。PA-DSSとの比較として、一番大きな違いは、要件モジュールという考え方が導入されていることです。すべての対象に適用されるコア要件と、特定の対象に適用される要件モジュールとで構成されています。バージョン1.0ではアカウントデータを伝送・処理・保存するアプリケーションを対象とするモジュールAのみとなっていますが、先ほどご紹介した通り、バージョン1.1でTerminal Softwareを対象とするモジュールの追加が予定されていることがアナウンスされています。

PA-DSSの要件とSecure Software Standardのコントロール目標を比較してみましょう。PA-DSSバージョン3.2の要件が具体的かつ詳細に記されているのに対し、Secure Software Standardのコントロール目標は抽象的であり、一般的な内容になっています。

Secure Software Standardの階層構造を見ると、一番上にコア要件または要件モジュールがあり、その配下にセキュリティ目標があります。その下に複数のコントロール目標が設定されていて、さらにその下にサブのコントロール目標とテスト要件とガイダンスの三つの項目が並列で配置されているといった構造です。Secure SLCの場合は、要件モジュールがないのでセキュリティ目標が階層の最上位になりますが、それ以降はSecure Software Standardと同様です。

将来的にほかのPCIのソフトウェア系基準がSecure Software Standardにマージされる際は、要件モジュールとして追加されると思われます。そうすると、マージされた基準の適用対象になるソフトウェアにはコア要件の準拠も求められるようになるでしょう。つまり、もしP2PEのドメイン2がSSFにマージされた場合は、SSSのコア要件にも準拠しなければならないということになるので、そうなった時のインパクトは、かなり大きいだろうと考えています。

Secure Software Standardのコントロール目標の内、注目されるものについていくつかご紹介します。まず、リスク評価に関するコントロール目標が多く追加されています。これはPA-DSSにはなかったものです。

次に機密情報の保護に関するコントロール目標の中に、伝送されるデータに対するものがあります。PCI DSSでは要件4.1、PA-DSSでは要件11.1で、オープンパブリックネットワークで伝送されるカードデータに対してのみ暗号化が求められているのに対して、Secure Software Standardではすべての伝送データを保護することが求められています。

暗号の利用に関するコントロール目標では、テスト要件まで見ないとわからないのですが、同等ビット強度として128bit以上が要求されていますので、TDESが使えないということに注意が必要です。それから乱数生成に関して、認定されたアルゴリズムやライブラリを用いて生成された乱数のみを使用することが求められています。これもPCI DSSやPA-DSSでは求められていなかったことです。

攻撃の検知に関するコントロール目標も、満たすのが大変そうだと思います。

アカウントデータの保護に関するコントロール目標については、PANを保存する場合にトランケーション、インデックストークンとパッド、強力な暗号化のいずれかの方法で読み取り不能にすることとされています。PCI DSSやPA-DSSの１方向ハッシュがなくなっていることに注意が必要です。

次に、Secure Software Lifecycle（Secure SLC）Standardの概要について、ごく簡単にご説明いたします。4つのセキュリティ目標の内、後半の二つ、安全なソフトウェアとデータの管理、セキュリティに関する情報伝達と、それらの配下のコントロール目標についてはPA-DSSにも同様な要件があるので、対応の難易度はそれほど高くないと思われます。一方、前半の二つのセキュリティ目標であるソフトウェアセキュリティのガバナンスと安全なソフトウェアエンジニアリング、およびそれらの配下のコントロール目標については、PA-DSSには含まれない、あるいは詳細化された項目が多く、相対的に対応の難易度が高いと思われます。

最後に、要点のまとめです。Software Security Frameworkについてご紹介しましたが、これはソフトウェアを認定対象とするSecure Software Standardと、開発ベンダを認定対象とするSecure SLC Standardの2つの基準と関連プログラムで構成されています。

PA-DSSとの相違点として、Objective-based Approachについてご説明しました。また、そのほかのPCI基準との関係というところで、もしP2PEドメイン2（P2PEアプリケーションに関する要件）が統合された場合には、国内でのインパクトが大きいかもしれないということを申し上げました。P2PEドメイン2のSSFへのマージについては、現状PCI SSCからは何の公式のアナウンスもありませんが、いくつかの断片的な状況証拠を上げて、その可能性についてご説明しました。P2PEを利用されている加盟店、あるいは、P2PEのソリューション・アプリケーションを提供されているベンダにおいては注意が必要になると考えられます。

※本記事は2020年11月13日に開催された「ペイメントカード・セキュリティフォーラム2020」のNTTデータ先端技術株式会社セキュリティ事業本部セキュリティコンサルティング事業部コンサルティングサービス担当チーフコンサルタント佐藤功視氏の講演をベースに加筆/修正を加え、紹介しています。

▶▶▶後編に進む

■お問い合わせ先
NTTデータ先端技術株式会社
セキュリティ事業部 Thales製品担当
〒104-0052
東京都中央区月島1-15-7
パシフィックマークス月島7F
TEL：03-5859-5422
URL：http://www.intellilink.co.jp
E-mail：il-HSM-sales@intellilink.co.jp