PCI の新たなソフトウェアセキュリティ基準 Software Security Framework - その5:SSFの認定プログラムとまとめ
PCI SSCの新しいソフトウェアセキュリティ基準であるPCI Software Security Framework (SSF)を紹介する本コラム、今回のその5で最後となります。本稿ではSSFを構成する2つの基準であるPCI Secure Software StandardとPCI Secure Software Lifecycle (Secure SLC) Standard、それぞれの認定プログラムについて紹介します。
なお、本稿におけるSSF関連文書の和訳は弊社独自のものであり、PCI SSC公式のものではないことをご承知おきください。正確な内容を把握したい場合は、必ず原文の基準書等を参照していただくようお願いいたします。
Secure Software Standardの認定プログラム
Secure Software Standard (公式な略称ではありませんが、以下SSSと略記する場合があります)の認定プログラムについては、Secure Software Standard Program Guide[1]に詳しく定められています。SSSの審査は、PCI SSCから認定を受けたSecure Software Assessor (SSA)が実施します*ⅰ。開発ベンダーが自社ソフトウェアのSSS認定を受けるためには、ベンダーはSSAと契約して審査を受け、SSAが審査結果をReport of ValidationとAttestation of Validationにまとめ、PCI SSCに提出してレビューを受ける必要があります。PCI SSCのレビューをパスすると、申請したソフトウェアはSSS認定ソフトウェアとしてPCI SSCのwebサイトに掲載されます。この認定プロセスの流れについては、PA-DSSと大きく変わる所はありません。
次に、SSS認定を受けたソフトウェアが認定を維持するプロセスについて説明します。認定を維持するためには、ソフトウェアに変更がない場合でも年次検証が必要です。これはPA-DSSの年次検証と同様で、実施方法も同様にベンダーの自己検証となります。PA-DSSと異なるのは、変更がない場合でも3年ごとにSSAによる再審査が必要になる点です。
さらに変更がある場合の検証についても、PA-DSS と大きく異なる点があります。
ソフトウェアに変更がある場合、その内容によって変更種別が定められており、変更種別ごとに検証方法が変わってくることはPA-DSSと同様なのですが、一つ目の大きな相違点として、変更種別の定義が挙げられます。特に No Impact が無くなっていることが大きな違いになると思います。SSSの変更種別について、表1にまとめました。
- *ⅰ: QSAやPA-QSAと同様、SSAと言った時にはそれが審査会社を指す場合と、審査会社の従業員で審査資格を持った者を指す場合、およびその両方の意味を含む場合があります。
変更種別 | 内容 | 備考 |
---|---|---|
High Impact (影響大) | 機密データ、機能、リソースを扱う、または影響を及ぼす(interact with)すべての変更 | PA-DSS では Low Impact と見なせた変更の多くが High Impact 扱いになると思われる |
Low Impact (影響小) | 任意のソフトウェアアーキテクチャ、ソースコード、コンポーネントに対する変更で、High impact に該当しないもの | PA-DSSと異なり、セキュリティに影響がなくてもソースコードに修正が入るとLow Impact 以上になる |
Administrative (管理) | アプリケーションの名称や、ベンダー会社自体の情報などの、Listing 情報に関する変更 | PA-DSSと同じ |
表1 SSSの変更種別
ソースコードに修正が入る場合、それがセキュリティに影響しなければPA-DSSではNo Impact になりましたが、SSSでNo Impact が無くなったということは、ソースコードに修正が入る場合は必ずLow Impact以上になることを意味します。一方PA-DSS では、High ImpactとLow Impactのいずれに該当するかについて、影響する要件の数や変更のボリュームなどによって評価する必要がありましたが、SSS では機密データに影響を及ぼす変更はすべてHigh Impactとなったので、ある意味分かりやすくなったと言えます。大雑把に言えば、PA-DSSのNo ImpactがSSSのLow Impactに変更され、PA-DSSのHigh/Low ImpactはSSSのHigh Impactに統合されたイメージになると思われます。
もう一つの大きな相違点は、ベンダーが Secure SLC 認定を受けているかどうかによって評価方法が変わって来ることです。これについてまとめたのが表2および表3になります。
申請種別 | 評価方法 | 頻度 | ||
---|---|---|---|---|
審査会社による評価 | ベンダー自己評価 自己検証 | ベンダーの差分レビューによる自己評価、および審査会社によるテスト | ||
最初の審査・ フル審査 | ✔ | 3年ごと (最初の審査後) |
||
High Impact (フル審査) | ✔ | 変更の実装ごと | ||
年次検証 | ✔ | 1年ごと | ||
Administrative | ✔ | 変更の実装ごと | ||
Low Impact | ✔ | 変更の実装ごと |
表2 変更種別ごとの評価方法:Secure SLC 認定ベンダーでない場合
申請種別 | 評価方法 | 頻度 | |
---|---|---|---|
審査会社による評価 | ベンダー自己評価 自己検証 |
||
最初の審査・ フル審査 | ✔ | 3年ごと (最初の審査後) |
|
High Impact (フル審査) | ✔ | 変更の実装ごと | |
年次検証 | ✔ | 1年ごと | |
Administrative | ✔ | 変更の実装ごと | |
Low Impact | ✔ | 変更の実装ごと |
表3 変更種別ごとの評価方法:Secure SLC 認定ベンダーの場合
ベンダーが Secure SLC 認定を受けていない場合は、変更種別ごとの検証方法は PA-DSS と大きく変わりません。しかし変更種別自体の定義が変わりNo Impactが無くなっているので、ソースコードの修正が入った場合は常に審査会社に審査を依頼する必要があり、ベンダーにとっては非常に大きな違いとなっています。一方、ベンダーが Secure SLC 認定を受けている場合は、Low Impact の場合に自己評価できるので、PA-DSSの認定維持プロセスに近い運用にできると思われます。
もともと Secure SLC は、AgileやDev/Opsなどのサイクルの早い開発手法を使っているベンダーを考慮して策定されたとアナウンスされており、認定の取得も任意となっている訳ですが、変更時の検証については上記の通り、Secure SLC 認定を取得しないベンダーの場合、PA-DSSとは状況が大きく異なるので注意が必要です。
Secure SLC Standardの認定プログラム
次に、Secure SLCの認定プログラムについて紹介しましょう。こちらも詳細はSecure SLC Standard Program Guideで定められていますが、初回の認定プロセスについてはSSSと同様です。審査はPCI SSCから認定を受けたSecure Software Lifecycle Assessor (SSLCA)が実施し、SSLCAは審査結果をReport of Compliance とAttestation of ComplianceにまとめてPCI SSCに提出し、PCI SSCのレビューをパスすると、開発ベンダーはSecure SLC認定ベンダーとしてPCI SSCのwebサイトに掲載されます。
SSS同様、Secure SLC でも変更種別と、それらに対する評価方法が定められています。
Secure SLCの変更種別は表 4の通りです。
変更種別 | 内容 |
---|---|
Designated (指定) | Secure SLC開発における製品カテゴリの変更、または削除。 ※製品カテゴリ:ベンダーが開発しているアプリケーションが、どのような業態向けであるかの種別。詳細はProgram Guide A.3を参照。 |
Administrative (管理) | ベンダーのSecure SLC準拠状況に影響しない変更。 例)社名などの変更、リストの「記述」欄の内容変更 |
表4 Secure SLC の変更種別
これらの変更種別に対して、評価方法は表5のように定められています。
申請種別 | 評価方法 | 頻度 | |
---|---|---|---|
審査会社による評価 | ベンダー自己評価 自己検証 |
||
最初の審査・ フル審査 | ✔ | 3年ごと (最初の検証後) |
|
年次検証 | ✔ | 1年ごと | |
Administrative | ✔ | 変更発生時 | |
Designated | ✔ | 変更発生時 |
表5 Secure SLCの変更種別ごとの評価方法
なおProgram Guideに、変更があった場合の認定の更新方法を示すフローチャートがあります(図1)。
図1 Secure SLC認定ベンダーに変更があった場合の更新方法の確認フロー
(引用元:Secure SLC Program Guide v1.0[2] p.12, Figure 3. 赤枠は筆者追記)
この中に “Is this a Low impact (Delta) change?” という項目がありますが(図の赤枠)、表4の通りSecure SLCの変更種別にLow Impactはありません。これについてPCI SSCに確認したところ、Figure 3 の”Low impact change”は”Designated change”の間違いであるとの回答でした。従って、AdministrativeでもDesignatedでもない変更の場合は、フル審査が必要ということになります。
まとめ
今回を含めて5回にわたって、PCI SSCの新たなソフトウェアセキュリティ基準PCI Software Security Frameworkについて紹介してきましたが、いかがでしたでしょうか。
最後にあらためてSSF全体についてまとめて、本コラムシリーズの筆をおかせていただきます。
Software Security Frameworkの構成
- ソフトウェアを認定対象とするSecure Software Standardと、開発ベンダーを認定対象とするSecure Software Lifecycle Standardの二つの基準、およびその認定プログラムから構成される。
- Secure Software StandardがPA-DSSの直接の後継と考えられる。Secure SLC Standard認定の取得は任意となっている。
- Objective-based Approachに基づいて新たに策定されており、PCI DSSやPA-DSSの要件に相当するものは、コントロール目標(Control Objective)となっている。
PA-DSSとの相違点・注意点
- 認定対象ソフトウェアの広がり:配布形態によらなくなったため、特にSaaSのようなクラウドで提供されるソフトウェアも対象に含まれる。
- 保護対象の広がり:アカウントデータ以外でも、機密性・完全性が求められるデータは保護対象となる。
- SSSの変更種別には、PA-DSSにあった No Impact が無くなっており、ソースコードの修正が入ると必ずLow Impact以上になる。
- Secure SLC認定ベンダーであればSSS認定ソフトウェアのLow Impact changeは自己検証できるが、Secure SLC認定ベンダーでない場合は、ベンダーの自己評価に加えてSSAによるテストが求められる。
Objective-based Approachの考え方
- PCI DSS/PA-DSS のような具体的な頻度や厳密さは(ほぼ)定められていない。
(There is no “one size fits all” method to software security) - 頻度や厳密さを決める根拠となるベンダーのリスク評価が非常に重要と思われる。
- 今後、他の PCI の基準にも波及してくることが想定される。
PA-DSSからの移行
- SSFの認定プログラムは開始されていて、2020/7現在はPA-DSSとの並存期間となっている。
- PA-DSSは、最新のv3.2が終息する2022/10/28でプログラム自体が終了する。新規の認定申請は2021/6/30まで受け付け。以降、プログラム終了まで既存の認定アプリケーションの変更申請は可能。
- 既存のPA-DSS認定アプリケーションは、2022/10/28までは現在と同じ扱い。2022/10/28以降は、すべての認定アプリケーションが「既存の導入済みのみ認められる」のステータスとなる。
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 Program Guideを含む SSF 関連基準、およびサポート文書等がリスト表示されます。 - [2] 参考文献[1]のリストの中に "Secure SLC Program Guide" があります。
Tweet