現在地

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

前回のコラムその1では、PCI SSCの新しいソフトウェアセキュリティ基準であるPCI Software Security Framework (SSF)の概要を紹介しました。本稿ではSSFを構成する2つの基準であるPCI Secure Software StandardとPCI Secure Software Lifecycle (Secure SLC) Standardの内、前者のSecure Software Standard[1]について、PA-DSS(Payment Application Data Security Standard: 決済アプリケーションデータセキュリティ基準)と比較してどのような点が変わっているかの概要を紹介します。
なお、2019年5月末に公開されたPCI SSC公式ブログ[2]ではSoftware Security FrameworkをSSFと略しているので、これ以降、本稿でもそのように記載します。また本稿におけるSSF関連文書の和訳は当社独自のものであり、PCI SSC公式のものではないことをご承知おきください。正確な内容を把握したい場合は、必ず原文の基準書等を参照していただくようお願いいたします。

前回の記事でも触れましたが、開発ベンダーが認定対象となるSecure SLCに対して、ソフトウェアが認定対象となるSecure Software StandardはPA-DSS[3]の直接の後継となる基準と考えられます。そこでコントロール目標*iの内容を紹介する前に、今回のコラムではPA-DSSと比較しながらどのような相違点があるかを見ていきましょう。なお、Secure Software Standard はSSFのような公式の略称が無いのですが*ii、毎回書くには長すぎるので本稿ではSSSと省略して記載する場合があります。

  • *i:「その1」でも紹介しましたが、間が空いてしまったのでおさらいすると、PA-DSSやPCI DSSの要件(Requirements)に相当するものを、SSFではコントロール目標(Control Objectives)と呼んでいます。
  • *ii: 最初のRFC版の段階ではS3という略称も使われていたのですが、2nd RFC版の際にこの略称は削除されました。

対象となるアプリケーション/ソフトウェア、対象とならないアプリケーション/ソフトウェア

SSSでは、対象となるアプリケーション/ソフトウェアの範囲が拡張されています。これは2019年6月にリリースされたProgram Guideで定義されています。
PA-DSSとSSSの間の最も大きな違いとして、SSSではソフトウェアの配布形態に制限がないことが挙げられます。PA-DSSの場合は、パッケージやライセンスなどの販売形式で提供されるアプリケーションのみが対象となっていました。SSSでは配布形態によらないとされたことで、特にSaaSとして提供されるソフトウェアが対象に含まれることになりました。もう一つの相違点として、OSやデータベースなどについてPA-DSSでは単に適用されない(Does Not Apply to)とされていましたが、SSSでは、決済ソフトウェアと一体化されていない限りは不適格(INELIGIBLE)という記載に変わりました。従ってOS/データベースについても、決済ソフトウェアと一体化されたコンポーネントであれば、対象に含まれると読み取れます。
それ以外については大枠では変わらず、受託開発などの特定一社向けのソフトウェアや、事業体の内製ソフトウェアなどは対象となりません。モバイルアプリについては、RFCの段階では対象になる可能性が示唆されていましたが、最終的にはモバイルPOSのような、一般消費者向けのスマートフォンやタブレット上で動作するソフトウェアについては対象外とされており、大きな違いはないと考えられます。

保護対象とするデータ

PA-DSSで保護対象データとして定められていたのは、PCI DSSと同じくアカウントデータ、つまりカード会員データと機密認証データでした。
一方Secure Software Standardでは、機密データ(Sensitive Data)が保護対象であるとされています。ここでいう機密データとは、用語集[1]で以下のように定義されています。(ここでは正確を期すために、原文も引用します)

In the context of the Software Security Framework, any data that requires protection from unauthorized disclosure (confidentiality) or modification (integrity).

Software Security Frameworkの文脈では、承認されていない開示(機密性)または変更(完全性)からの保護が要求される全てのデータのこと。

この定義に続いて、機密データに含まれるものの例として、カード会員データ、機密認証データ、トークン、暗号鍵マテリアル、認証情報、内部システム情報、およびその他ベンダーの定義する保護の必要なデータが挙げられています。実際にはPCI DSSとPA-DSSでも、個別の要件で暗号鍵マテリアルや認証情報などの保護は求められていますが、Secure Software Standardではそれらも保護対象に含まれることが明確化されたと言えるでしょう。また最後の「その他ベンダーの定義する保護の必要なデータ」については、その1で説明した、ベンダーに強固なリスク管理プロセスが求められていることと関係していると考えられます。つまり、リスク管理プロセスの最初のステップである重要な資産の識別によって、上記に列挙された以外の重要なデータが見つかった場合、それらについても保護対象とすることが求められていると考えられます。なお重要な資産の識別は、コントロール目標1で求められています。

ベースとなる基準

PA-DSSはPCI DSSを基に構成されています。実際 PA-DSSの要件は、PCI DSSの要件の中から決済アプリケーションと開発ベンダー(開発プロセス)に適用されるものを抽出したサブセットに加えて、実装ガイドやバージョニング方法論などの、いくつかのPA-DSS特有の要件から構成されています。
これに対してSecure Software Standardは、PCI DSSおよびPA-DSSとは観点の異なるObjective-based Approachに基づいて完全に新しく策定された基準となっており、PA-DSSとは大きく異なる構成となっています。

要件モジュール

Secure Software Standardでは、新たに要件モジュール(Requirement Modules)という考え方が導入されています。Secure Software Standardのコントロール目標は、すべての対象に適用されるコア要件(Secure Software Core Requirements)と、特定の対象に適用される要件モジュールの大きく二つに分けられます。SSS v1.0で定義されている要件モジュールはアカウントデータに適用されるモジュールAのみですが、この考え方が導入された背景は、その1でも触れた、将来的に他のPCI基準の要素がSSFに統合されるかもしれない、ということを見越したものと思われます。つまり、他のPCI基準のソフトウェアに関する要素がSSFに統合される際は、要件モジュールとして追加されるものと思われます*iii

  • *iii: 2020/5/21 から1カ月間、Terminal Softwareを対象とするModuleのRFCが実施されて、このModuleを含んだSSSが2020年末にv1.1としてリリース予定とアナウンスされています[4]

要件とコントロール目標

次に、PA-DSSの要件とSecure Software Standardのコントロール目標を最上位レベルで比較してみましょう(表1)。両者を比較すると、文言が長く具体的なPA-DSSの要件と比べて、Secure Software Standardのコントロール目標はより抽象的で、ふわっとした印象です。

PA-DSS v3.2 要件
1: 完全なトラックデータ、カード検証コードまたは値、またはPINブロックデータを保存しない
2: 保存されるカード会員データを保護する
3: 安全な認証機能の提供
4: ペイメントアプリケーションの動作のログ
5: 安全なペイメントアプリケーションの開発
6: ワイヤレス送信の保護
7: 脆弱性に対応し、ペイメントアプリケーションのアップデートを維持するために、ペイメントアプリケーションをテストする
8: 安全なネットワーク実装の促進
9: カード会員データをインターネット接続のサーバに保存してはならない
10: ペイメントアプリケーションへの安全なリモートアクセスの促進
11: 公共ネットワークでのセンシティブトラフィックの暗号化
12: すべてのコンソール以外の管理アクセスを安全にする
13: 顧客、リセラー、インテグレータ向けの『PA-DSS実装ガイド』の維持
14: PA-DSSの責任を担当者に割り当てること、および担当者、顧客、リセラー、インテグレータ向けのトレーニングプログラムの保守
Secure Software Standard v1.0 コントロール目標
コア要件
1: 重要な資産の識別
2: 安全なデフォルト
3: 機密データの保持
4: 重要な資産の保護
5: 認証とアクセス制御
6: 機密データの保護
7: 暗号の利用
8: 活動の追跡
9: 攻撃の検知
10: 脅威と脆弱性の管理
12: ベンダーセキュリティガイダンス
モジュールA
A.1: 機密認証データ
A.2: カード会員データの保護

表1 PA-DSSの要件とSecure Software Standardのコントロール目標

スコープ(対象範囲)

Secure Software Standardのスコープを表2にまとめました。

Secure Software Standard v1.0 のスコープ(対象範囲)
・ソフトウェアセキュリティ対策を識別、サポートするためにベンダーが用いるプロセス
・すべてのペイメントアプリケーションの機能(以下が挙げられるが、これらに限定されない)
  1. エンドツーエンドのペイメント機能
  2. 入力と出力
  3. エラー状況の扱い
  4. 他のファイル、システム、またはソフトウェアやソフトウェアコンポーネントへのインターフェイスと接続
  5. すべてのデータフロー
  6. すべてのセキュリティ機構、対策(control)、対抗策(countermeasure)(例:認証、認可、検証、パラメータ化、セグメンテーション、ログなど)
・ベンダーセキュリティガイダンスが保証すべき事項:
  1. 顧客に、ペイメントソフトウェアの安全な実装と操作をする方法を認識させ、
  2. 実行環境とシステムコンポーネントの設定オプションに対するガイダンスを提供し、
  3. セキュリティアップデートをどのように実装するかのガイダンスを提供し、
  4. 顧客および他のステークホルダーに、セキュリティに関する事項をどのように、どこへ報告するかを認識させる
注)ソフトウェアベンダーは、以下のような場合でも、特定の設定についてガイダンスを提供することを期待される可能性がある:
  1. ソフトウェアを顧客がインストールした後はペイメントソフトウェアベンダーが制御できない場合、または
  2. ソフトウェアベンダーではなく顧客の責任である場合
・レビューされるペイメントソフトウェアに対してサポートされるすべてのプラットフォームと実行環境
重要な資産にアクセスするためにペイメントソフトウェアによって、またはペイメントソフトウェア内で使用されるツール(レポートツール、ログツール)と機能(システムコールやAPI)
サポートする実行プラットフォームまたは環境、サードパーティおよびオープンソースのライブラリ、サービス、および他の要求される機能性を含む、すべてのペイメントソフトウェアコンポーネントと依存性の範囲
・ペイメントソフトウェアの完全な実装に必要なその他のソフトウェアのタイプの範囲

表2 Secure Software Standardのスコープ

赤字部分はPA-DSS→Secure Software Standardで追加された項目を示しています。考え方としては大きく変わっていませんが、ポイントとして以下の3点が挙げられると思います。

  • 「ソフトウェアセキュリティ対策を識別、サポートするためにベンダーが用いるプロセス」というリスク評価に関する項目の追加
  • PCI DSSに準拠する、という言い回しがなくなり、ペイメントソフトウェアのセキュリティなどの言葉に一般化
  • サポートする実行プラットフォームまたは環境等も対象範囲となることが明確化

逆にPA-DSSにはあってSSSでは削除された項目として、アプリケーションのバージョン体系の定義(Versioning Methodology)がありますが、これはSecure SLC Standardの方に引き継がれています。

要件/コントロール目標と階層構造

PA-DSSでは、図 1のように14個の要件の下に、PA-DSS要件/テスト手順/ガイダンスが並列に配置された構成となっていました。

図1 PA-DSS 要件の階層構造

図1 PA-DSS 要件の階層構造

Secure Software Standardの場合は、もう少し複雑な階層構造になっています。文章で説明すると分かりにくいと思うので、図 2を見ていただく方が良いかと思います。

図2 Secure Software Standard 要件の階層構造

図2 Secure Software Standard 要件の階層構造

先ほど説明したようにまずコア要件と要件モジュールの二つに分かれていて、その下にセキュリティ目標(Security Objectives)があり、セキュリティ目標の下にコントロール目標があって、最後にその下にコントロール目標/テスト要件/ガイダンスが並列に配置されるという階層構造になっています。

コア要件配下のセキュリティ目標は以下の4つです。

  • 攻撃可能面の最小化(Minimizing the Attack Surface)
  • ソフトウェアの保護メカニズム(Software Protection Mechanism)
  • 安全なソフトウェアのオペレーション(Secure Software Operations)
  • 安全なソフトウェアライフサイクル管理(Secure Software Lifecycle Management)

一方、モジュールA配下のセキュリティ目標は1つだけです。

  • アカウントデータの保護(Account Data Protection)

なおモジュールAは、通常のカード情報を扱う決済ソフトウェアであれば適用対象になるので、PA-DSS認定アプリケーションがSecure Software Standard認定に移行する場合は、モジュールAも適用対象になると思われます。

まとめ

PCI SSCの新たなソフトウェアセキュリティ基準PCI Software Security Frameworkを構成する決済ソフトウェアに対する基準Secure Software Standardについて、PA-DSSと比較してどのような点が変わっているかについて紹介しました。PA-DSSと比較すると、対象となるアプリケーション、保護対象となるデータ、スコープなど、さまざまな面で拡張・整理された基準となっていることがお分かりいただけたかと思います。次回は、SSSのコントロール目標について、もう少し詳しく見ていきたいと思います。

Writer Profile

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

参考文献