PCI SSCの新しいソフトウェアセキュリティ基準であるPCI Software Security Framework (SSF)を紹介している本コラム、今回はSSFを構成する2つの基準であるPCI Secure Software StandardとPCI Secure Software Lifecycle (Secure SLC) Standardの内、後者のSecure SLC Standard ^[1]について紹介します。
その1でも紹介しましたが、Secure Software Standardがソフトウェアを認定対象とするのに対して、Secure SLC Standardは開発ベンダーが認定対象となること、また認定取得はオプションであることがSecure Software Standardとの大きな違いです。開発ベンダーには、セキュアで成熟した開発プロセスを保持し、維持・運用することが求められます。
なお、本稿におけるSSF関連文書の和訳は弊社独自のものであり、PCI SSC公式のものではないことをご承知おきください。正確な内容を把握したい場合は、必ず原文の基準書等を参照していただくようお願いいたします。

スコープ（対象範囲）

まずはSecure SLCのスコープを以下の表1にまとめました。

表1　Secure SLCのスコープ

赤字部分がSecure SLCで追加された項目となっています。PA-DSSから多くの項目が追加されているようにも見えますが、実際にはPA-DSSの個別要件に含まれているものも多く、それらが明示化されたものと考えられます。ベンダーセキュリティガイダンスは、その3でも触れたようにPA-DSSの実装ガイド(Implementation Guide)に相当するものと考えられます。

サードパーティサービスプロバイダ

PA-DSSにはなかった要素として、サードパーティサービスプロバイダ（委託先）に関する補足があります(Secure SLC p.9)。想定される委託業務の例として、

• コードレビュー、もしくは他のソフトウェアテストの実施
• 開発環境や配布環境のホスティング
• ソフトウェア製品のインテグレーションおよびインストール

などが挙げられています。

Secure SLCに関連する事項を外部委託する場合の考え方はPCI DSSと同様で、どのSecure SLC要件がどちらの責務であるかを識別する必要があり、以下の事項を含む委託先管理プロセスを持つことが期待(expected)されています。

• 契約前のデューデリジェンス
• セキュリティの責任範囲についての定義
• 合意した責任範囲が合致していることの定期的な確認
• 両社がセキュリティの責任範囲を理解し、認める事を保証する合意文書

また、ベンダーから業務委託を受けるサービスプロバイダの立場から見てみると、決済ソフトウェアのセキュリティに関する最終的な責務はベンダーにあるものの、サービスプロバイダはベンダーから、合意した責任範囲についてSecure SLCの要件を満たしていることを示すことが求められると想定されます。その方法としては、サービスプロバイダが該当する要件に対してベンダーとは別にSecure SLCの評価を受けて準拠するか、ベンダーのSecure SLC評価と一緒に評価を受けるかのいずれかとされており、この点もPCI DSSと同様です。

Secure SLC のコントロール目標

Secure SLCには、Secure Software Standardの要件モジュールの考え方はありませんが、コントロール目標の階層構造自体は同じです。Secure Softwareコア要件に相当するものとして、単にSecure SLC要件があり、その下には以下の4つのセキュリティ目標が挙げられています。

• ソフトウェアセキュリティのガバナンス(Software Security Governance)
• 安全なソフトウェアエンジニアリング(Secure Software Engineering)
• 安全なソフトウェアとデータの管理(Secure Software and Data Management)
• セキュリティに関する情報伝達(Security Communications)

ここからは「その3」と同様に、セキュリティ目標ごとに配下のコントロール目標を見ていきましょう。

ソフトウェアセキュリティのガバナンス (Software Security Governance)

PA-DSSでは要件14でPA-DSSに関する責務の割り当てが求められていました。PA-DSSの要件は優先度順に並んでいて、要件14は最後の要件です。これとは対照的にSecure SLCではコントロール目標1として、責務に関するコントロール目標が最初にあり、さらに上級首脳陣(senior leadership team、CxO)によって責務を割り当てられることが求められています（PA-DSSでは、誰が責務を割り当てるかまでは要件に記載されていませんでした）。また年次での実施が求められている事項として、ソフトウェアセキュリティポリシー・戦略のパフォーマンスおよび変更点の上級首脳陣への提供、ソフトウェア開発者がセキュリティに関する責務を果たすために必要なスキルを維持していることを確認するレビュープロセスがあります。
コントロール目標2では、ベンダーのセキュリティに関するポリシー・戦略の整備・維持が求められています。直接的には該当するPA-DSS要件はない部分で、セキュリティ戦略の策定からそのパフォーマンスのモニタリングまでが要求されており、対応の難易度は高いように思われます。年次での実施が求められている事項として、規制や業界のセキュリティに関するソースおよびコンプライアンスの要件変更についてのレビュー、セキュリティ戦略についてのレビューがあります。

安全なソフトウェアエンジニアリング (Secure Software Engineering)

コントロール目標3および4では、脅威の識別と緩和、および脆弱性の検知と緩和が求められています。コントロール目標3.1では、重要な資産の識別が求められていて、一見Secure Software Standardのコントロール目標1と重複しているようにも思えますが、テスト要件レベルで比較をしてみると、Secure Software Standardの方では決済ソフトウェアに対して識別を実施した具体的な結果（記録）を確認することが求められているのに対して、Secure SLCでは識別プロセスそのものを確認することが求められているという違いがあります。従って具体的には、重要な資産の識別に関するポリシーや手順書、実施記録用のひな形などを確認することになると思われます。Secure SLC には、これ以外にも一見Secure Software Standardと重複しているように見受けられるコントロール目標がありますが、それらは確認対象が異なっており、Secure SLCではプロセスそのものが確認対象となっている場合が多いです。

安全なソフトウェアとデータの管理 (Secure Software and Data Management)

コントロール目標5は変更管理で、PA-DSSでは主に要件5.3および5.4で求められる内容に相当します。ソフトウェアのバージョン体系を含む管理方法もここに含まれます。
コントロール目標6はソフトウェアの完全性の保護となっています。PA-DSSでは、要件5.1.5でソースコードの完全性、要件7.2.2でパッチやアップデートを配信する際の完全性が求められていましたが、これらが包括的に一つのコントロール目標にまとめられたものと考えられます。特にソースコードの完全性について、サードパーティコンポーネントも対象に含まれる点には注意が必要と思われます。
コントロール目標7の機密データの保護はSecure Software Standardのコントロール目標6と名称は同じですが、下位のコントロール目標を比較してみると、Secure Software Standardでは決済ソフトウェアが保持するデータが対象となっているのに対して、Secure SLCではベンダーのシステム上で保持される顧客の機密データを対象としている点が異なります。コントロール目標7.1のガイダンスを見ると、ベンダーが機密データを取得する理由の例として、トラブルシューティングやデバッグ目的が挙げられており、これはPA-DSSの要件2.3で求められていた内容に相当すると考えられます。

セキュリティに関する情報伝達(Security Communications)

コントロール目標8はベンダーセキュリティガイダンス(VSG)に関する項目です。Secure Software Standardの同名のコントロール目標12と比較してみると、Secure Software Standardの方はガイダンス自体の内容の確認がメインとなっているのに対して、Secure SLC Standardの方では内容についての確認は大まかなものとなっていて、ガイダンスの作成、維持、提供のプロセスの確認がメインとなっているという違いがあります。また年次での実施が求められている事項として、VSGのレビューがあります。
コントロール目標9では、ステークホルダーとの情報伝達チャネルを確立し、セキュリティに関する情報を伝達することが求められています。PA-DSSでは主に要件13、14などに含まれる内容となりますが、セキュリティパッチが適用できない場合の緩和策の提供なども求められており、より包括的な内容になっています。
コントロール目標10はソフトウェア更新の情報伝達に関する内容で、PA-DSSでは要件7.3に相当するものとなっています。

まとめ

PCI SSCの新たなソフトウェアセキュリティ基準PCI Software Security Frameworkを構成する基準の一つであるSecure Software Lifecycle Standardについて紹介しました。Secure SLC は、PA-DSS要件と同様のコントロール目標も含まれるものの、より詳細化されていたり、コントロール目標1,2のようなPA-DSSでは求められておらず、対応の難易度が高いと思われる項目も含まれていたりして、開発ベンダーが認定を受けるのは簡単ではないように見受けられます。取得はオプションなので、Secure SLC認定は受けないという選択肢も考えられますが、まだ紹介していないSecure Software Standard認定ソフトウェアの認定維持プロセスを考慮すると、かなり難しい判断になると思われます。ということで、次回はSecure Software StandardとSecure SLC Standardの認定プログラムについて、認定維持プロセスを中心に紹介したいと思います。

Writer Profile

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

参考文献

• [1] “PCI SSC Document Library”
  https://www.pcisecuritystandards.org/document_library の検索フォームのドロップダウンリスト Filter by で SOFTWARE SECURITY を選択すると Secure Software Lifecycle Stadard を含む SSF 関連基準がリスト表示されます。

• PCI DSS トータルサービス
• PCI訪問調査サービス
• Oracle AVDFサービス
• 改ざん検知 Tripwire Enterprise
• PCI DSS基本コース