現在地

PCI の新たなソフトウェアセキュリティ基準 Software Security Framework - その3:Secure Software Standardのコントロール目標

前回のコラムその2は、PCI SSCの新しいソフトウェアセキュリティ基準であるPCI Software Security Framework (SSF)を構成する二つの基準の内、PA-DSS(Payment Application Data Security Standard: 決済アプリケーションデータセキュリティ基準)の直接の後継基準となるPCI Secure Software Standardについて、PA-DSSと比較しながらどのような点が変わっているのかの概要を紹介しました。今回はSecure Software Standardのコントロール目標について、もう少し詳しく見ていきたいと思います(公式な略称ではありませんが、本コラムではSecure Software StandardをSSSと略記する場合があります)。
なお、本稿におけるSSF関連文書の和訳は当社独自のものであり、PCI SSC公式のものではないことをご承知おきください。正確な内容を把握したい場合は、必ず原文の基準書等を参照していただくようお願いいたします。

コア要件のコントロール目標

前回のコラムで、Secure Software Standardでは要件モジュールという概念が導入されており、Secure Software Standard v1.0では、コア要件とモジュールAの二つの要件モジュールから構成されていることを紹介しました。ここからは、まずコア要件のコントロール目標をセキュリティ目標ごとに見ていきましょう。

攻撃可能面の最小化(Minimizing the Attack Surface)

コントロール目標1:重要な資産の識別(Critical Asset Identification)
コントロール目標2:安全なデフォルト設定(Secure Defaults)
コントロール目標3:機密データの保持(Sensitive Data Retention)

コントロール目標1では、重要な資産の識別が求められています。PA-DSSの場合は、保護対象がカード会員データと機密認証データであることが前提となっているため、リスク評価に関するPA-DSS要件5.5でも重要な資産の識別は明確には求められていませんが、Secure Software Standardでの保護対象は、カード会員データおよび機密認証データを含むがそれらに限らない機密データとされていることから、まずは最初のコントロール目標として、保護対象を明確に定めることが求められていると考えられます。
コントロール目標2で求められる安全なデフォルト設定は、PA-DSSでは各要件に分散しているので対応が付けづらいですが、PCI DSSで言えば要件2で求められる内容に相当すると考えられます。
コントロール目標3では機密データを保持する際に求められる内容となっています。この中で機密データの「一時的(Transient)」、「持続的(Persistent)」という用語が出てくるので、用語集の説明から補足します。SSFでは、機密データは一時的と持続的の二種類に分類されます。一時的な機密データは、内部で生成され、利用後に安全に削除されることを意図した、揮発性メモリで保持される機密データとされています。一方、持続的な機密データは、不揮発性ストレージで保持される機密データとされています。何らかの処理をするために内部メモリ上のみで扱われるものが一時的機密データで、ファイルやDBなどに保存される(一時ファイルへの出力も含む)ものが持続的機密データということになります。コントロール目標3で求められている内容は、保護対象が機密データに拡張されていることを除けば、PA-DSSの要件1および2、PCI DSSの要件3で求められている内容に概ね相当すると考えられます。

ソフトウェアの保護メカニズム(Software Protection Mechanism)

コントロール目標4:重要な資産の保護(Critical Asset Protection)
コントロール目標5:認証とアクセス制御(Authentication and Access Control)
コントロール目標6:機密データの保護(Sensitive Data Protection)
コントロール目標7:暗号の利用(Use of Cryptography)

最初のセキュリティ目標「攻撃可能面の最小化」による対策を実施した後、次のセキュリティ目標「ソフトウェアの保護メカニズム」の最初のコントロール目標4では、残存している攻撃可能面に対する攻撃シナリオの識別とその対策の実装が求められています。ここでは、何か特定のセキュリティコントロールが求められている訳ではなく、識別した脅威に対して適切なリスク低減策を実装することが求められています。また、いわゆるセキュアコーディングによる対策は、SSSのコントロール目標やテスト要件を眺めても明記されていないのですが、コントロール目標4.2に含まれると考えられます。その理由は4.2のガイダンスに、ソフトウェアセキュリティコントロールとして、入出力のバリデーション、認証、パラメータ化、エスケープ、セグメンテーション、ロギングなどが含まれるとあるからです。
コントロール目標5は、おなじみの認証とアクセス制御です。PA-DSSでは主に要件3、PCI DSSでは要件7や8で求められる内容に相当すると考えられますが、Objective-based Approachの考え方に従って、例えばパスワードの文字種や桁数などは具体的に定められていません。ガイダンスでは参考文書としてNIST SP 800-63が挙げられているので、この内容を参照して実施するのが望ましいと考えられますが、SP800-63ではパスワードの変更は侵害が疑われる時や、ユーザから依頼があった時を除いてするべきではない、という項目があります。これは、パスワードの定期的変更を要件としているPA-DSS/PCI DSSに先んじて、ベストプラクティスに合わせる方向に舵を切っているように見受けられます。

コントロール目標6では、保存、および伝送される機密データの保護が求められています。この中のコントロール目標6.3は「暗号を利用する際は、本基準の全ての適用可能な暗号に関する要件を満たすこと」ですが、特にテスト要件6.3.aで、次のコントロール目標7に対する準拠を確認することが求められています。
コントロール目標7は、暗号の利用時に求められる内容になります。暗号アルゴリズムの選択や鍵管理に加えて、PA-DSSには無かった乱数生成器に関する項目も含まれます。またコントロール目標には明記されていませんが、テスト要件7.2.aで暗号鍵の同等ビット強度(equivalent bit strength)として少なくとも128ビット以上が求められています。従って、共通鍵暗号の場合はAES 128ビット以上が求められることになり、TDESは最高の3-keyでも鍵の同等ビット強度は112ビットのため、暗号アルゴリズムとして利用できないことになるので注意が必要です。公開鍵暗号の場合は、RSAは3072ビット以上、ECCは256ビット以上が必要になります。またテスト要件7.3.aでは、乱数生成器で生成する乱数のエントロピーが少なくとも128ビット以上のものを利用することが求められています。

安全なソフトウェアのオペレーション(Secure Software Operations)

コントロール目標8:活動の追跡(Activity Tracking)
コントロール目標9:攻撃の検知(Attack Detection)

PA-DSSでは要件4でログの取得が求められていますが、Secure Software Standardのコントロール目標8では、ロギングの代わりに活動の追跡(Tracking)という言葉になっています。テスト要件を見ると、ベンダーがトラッキングをしていることのエビデンスを確認することが求められているので、通常はログを確認することになると思われます。追跡という言葉に改められている理由はコントロール目標8.1のNoteに記載があり、実行環境によっては他のPCI基準で求められているような詳細なログの取得がサポートされていない場合があることを考慮して、他のPCI 基準におけるログ取得と区別するために、活動の追跡という言葉を使っているとのことです。取得するべきイベントとしては、重要な資産に対するアクセスに加えて、権限の昇格、機密データの暗号化の無効化、機密データの復号、他のシステムまたはプロセスへの機密データのエクスポート、認証の失敗、セキュリティコントロールまたは代替のセキュリティ機能の無効化または削除が挙げられていて、PA-DSSでは求められていなかった項目もあるので注意が必要です。
次のコントロール目標9は、特にPA-DSSからの移行を考えているベンダーにはインパクトが大きいと思われる項目で、ソフトウェアが攻撃などの異常な振る舞いを検知して警告することが求められています。PA-DSSの場合はPCI DSS準拠環境にインストールされることが前提となっているため、PCI DSSの要件10に含まれるログの日次レビューなどでカバーされている内容と考えられますが、Secure Software Standardではソフトウェアの機能として求められています。ガイダンスを見ると、ソフトウェア配布(導入)後の設定変更の検知や、自動化された攻撃の振る舞い検知(例えば、パスワードの繰り返し入力をブルートフォース攻撃の兆候を示すものとして検知する)が例として挙げられています。現行のPA-DSS認定アプリケーションで、このような機能を実装しているものはほぼ無いでしょうから、サードパーティのライブラリなどを利用するとしても、それなりの規模の修正や機能追加が必要になると思われます。

安全なソフトウェアライフサイクル管理(Secure Software Lifecycle Management)

コントロール目標10:脅威と脆弱性の管理(Threat and Vulnerability Management)
コントロール目標11:安全なソフトウェアの更新(Secure Software Updates)
コントロール目標12:ベンダーセキュリティガイダンス(Vendor Security Guidance)

4つ目のセキュリティ目標はソフトウェアライフサイクル管理となっています。ソフトウェアライフサイクルに関する項目がすべてSecure SLC Standardに移された訳ではなく、Secure Software Standardでも求められる内容があるので注意が必要です。このようなSecure SLCとSSSで重複しているように見受けられる項目については、テスト要件のレベルで比較してみると、Secure SLCではプロセスそのもの、SSSではプロセスの成果物が主な検証対象となっていると考えると理解しやすいと思います。
コントロール目標10は脆弱性管理で、PA-DSSでは要件7.1、および5.2で求められる内容に相当します。PA-DSS/PCI DSSでは、信頼性の高い情報源から脆弱性情報を収集し、ランク付けして、ランクに応じて対処すること、またPA-DSS要件5.2、PCI DSS要件6.5では、バッファオーバーフローやSQLインジェクションなどの具体的なコーディングの脆弱性に対して対応することが求められていました。Secure Software Standardでは具体的な脆弱性についての記載はありませんが、コントロール目標10.1では、OWASPやCWEなどの業界標準を参照して、対象ソフトウェアに対する一般的な攻撃手法をプラットフォームレベル、プロトコルレベル、言語レベルでリスト化し、リスト化した各攻撃に対する低減策を文書化しておくことが求められています。コントロール目標10.2では、リリース前に脆弱性が修正されていることを確認するテストの実施が求められています。
コントロール目標11では、更新ソフトウェアの配布タイミングと安全な配布方法に関する内容が求められており、これはPA-DSSの要件7.2と同様であると考えられます。
コントロール目標12は、ベンダーセキュリティガイダンス(VSG)を作成して、ステークホルダーに提供することが求められています。ベンダーセキュリティガイダンスは、PA-DSSの実装ガイドに相当するものと考えられます。PA-DSSとの違いとしてコントロール目標12では、VSGに含めるべき内容だけでなく、含めてはいけない内容―ウィルス対策ソフトなどのセキュリティに関する設定を無効化する方法や、必要以上に高い権限でソフトウェアを実行する方法など―も記載されていることが挙げられます。

モジュールAのコントロール目標

次にモジュールAです。先述の通り、モジュールAのセキュリティ目標は一つだけです。

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

コントロール目標 A.1:機密認証データ(Sensitive Authentication Data)
コントロール目標 A.2:カード会員データの保護(Cardholder Data Protection)

コントロール目標A.1では機密認証データを保存しないことが求められており、これはPA-DSS要件1、PCI DSS要件3.2に相当するものとなっています。
コントロール目標A.2ではカード会員データの保護が求められており、これはPA-DSS要件2、PCI DSS要件3.3、3.4に相当するものとなっています。一点、注意が必要なのは、コントロール目標A.2.3の保存PANを読み取り不能にする方法の中に、一方向ハッシュが含まれていない事です。PA-DSS認定アプリで、ハッシュを使ってPANを読み取り不能にしている場合は、Secure Software Standard認定に移行する際に対応が必要になると思われます。

PA-DSSからの移行とセキュリティガイドライン(「実行計画」の後継文書)における対応

今回のコラムの最後のトピックとして、PA-DSSからの移行について紹介しておきましょう。これについてはSSC公式ブログでアナウンス[1][2]されており、FAQ[3]にも記載があります。簡単にまとめると以下の通りです。

  • PA-DSS プログラムは2022/10末で終了。新規の申請は2021/6/30まで受け付け。
  • 既存のPA-DSS認定アプリは2022/10末までは、現在と同じ扱い(年次検証、および変更プロセス)で、2022/10末以降は「既存の導入済みのみ認められる」のステータスとなる

一方、国内の「実行計画」に基づく対応を考えると、その1で説明したように「非保持と同等/相当」を実現するための方法の一つ「技術要件11項目」の中の一つとしてPA-DSS認定POSアプリの利用があります。「実行計画」については、後継文書となる「クレジットカード・セキュリティガイドライン」[4]が公開されていますが、「技術要件11項目」についてはまだ更新されておらず、PA-DSS終息後の対応についての検討はこれからになると思われます。ただ、PA-DSSが終息する2022/10末以降はPA-DSSプログラム上、新規に導入することができなくなるので、「技術要件11項目」のPA-DSS認定POSアプリも、SSS認定のPOSアプリに置き換えられる可能性があります。従って、この方式で「非保持と同等/相当」を実現している加盟店やPOSアプリを提供しているベンダーは、SSS認定POSアプリへの移行を検討するか、DUKPT暗号化方式の導入やP2PEソリューションによる非保持と同等/相当への移行、または外回り方式による非保持化への移行などの検討が必要になると思われます。

まとめ

前回のコラムに続いて、PCI SSCの新たなソフトウェアセキュリティ基準PCI Software Security Frameworkを構成する決済ソフトウェアに対する基準Secure Software Standardについて紹介しました。今回はコントロール目標を少し詳しく見てみましたが、これらは以下の3つに分類できると思います。

  1. PA-DSSの要件と概ね対応を付けることができて、同様の対策で対応できそうなもの
  2. PA-DSSの要件と対応は付けられるけれど利用不可となるアルゴリズムがあり、場合によって実装を修正する必要があるもの
  3. PA-DSSでは求められておらず、新規で対応が必要になりそうなもの

特に最後の3.に該当するコントロール目標/テスト要件については対応難度も高そうなものがあり、開発ベンダーは審査を受ける前に十分な準備が必要になりそうです。
次回のコラム「その4」では、SSFを構成するもう一つの基準、Secure Software Lifecycle Standard について紹介する予定です。

Writer Profile

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

参考文献