2019年5月31日8:00
■NTTデータ先端技術株式会社
PCI Secure Software StandardのPA-DSSとの相違点
今までのPA-DSSと新たなSecure Software Standardとの比較で、主要な相違点を紹介します。まず認定対象について、今までのPA-DSSでは、ユーザーのオンプレミスの環境にインストールするようなパッケージのソフトウェアを対象としていましたが、新しいSecure Software Standardでは、これに加えてクラウドのようなSaaS型で提供するようなソフトウェアも対象にできるところが大きなポイントです。
保護対象とするデータですが、今までのPA-DSSは、PCI DSSと共通で、アカウントデータが対象です。アカウントデータというのは、カード会員データと機密認証データを総称したものです。これらが保護対象として決まっているのが1つの特徴でしたが、新しい基準では、機密データという新しい言葉が定義されており、これを保護対象としています。機密データの例としては、今までどおりのカード会員データや機密認証データも入りますが、これに加えてトークン、暗号鍵、暗号鍵のマテリアル、認証情報、内部システム情報など、あらゆる情報が対象になってきます。このような重要な情報資産を識別し、ソフトウェアのリスク評価の対象とする点も、これまでのアプローチとの違いとして表れています。
基準の構成として、PA-DSSでは全部で14要件ありました。基本的にはソフトウェアのセキュリティにかかわるPCI DSSの要件をピックアップして、それを並べ替えたような要件と、それにプラスアルファとして、「PA-DSS実装ガイド」という、ユーザー向けのガイダンスに関する要件が追加された構成になっています。
一方でSecure Software Standardでは、今まで要件（原文でRequirements）と呼んでいたものが、コントロール目標（原文でControl Objectives）と、名前が変わっています。1から12のコントロール目標をまとめてコア要件（原文でCore Requirements）と呼び、それにモジュールAという、モジュールが追加された構成になっています。コア要件は、すべてのソフトウェアに適用されます。それにプラスして、機密認証データやカード会員データを扱うアプリケーションはモジュール Aも適用される構成になっています。今までは機密認証データ、カード会員データを扱うことを大前提としていましたが、それがモジュールの扱いとなりました。おそらく今後、別の基準をSecure Software Standardに組み入れる場合を想定して、共通要件としてのコア要件と、個別の特徴に応じたモジュールを拡張できるように整理されたのだと思います。
Secure Software Standardの概要は？
Secure Software Standardは、12のコントロール目標とそれを4つにグルーピングしたセキュリティ目標（原文でSecurity Objectives）で構成されています。ここでは、コントロール目標単位で概要をご紹介します。
コントロール目標 1: Critical Asset Identification（重要な資産の識別）
先ほどご紹介した「機密データ」という定義に基づき、保護対象となる機密データ、機能やリソースを識別するという、PA-DSSにはなかった観点です。PA-DSSでもリスク評価の要件は一部あるにはありましたが、そもそも保護対象がカード会員データや機密認証データと決まっていましたので、資産の識別という観点はありませんでした。
コントロール目標 2: Secure Defaults（安全なデフォルト設定）
ベンダ提供のデフォルト値を使用しないことは、PCI DSSでもおなじみですが、ここはベンダ側の視点で、一般的に不必要な機能はデフォルトで無効化し、ビルトインアカウントや初期パスワードを使用させないように設定をサポートするものです。出荷時の設定は攻撃者に狙われるので安全なものに変更するよう、設定機能およびセキュリティガイダンスをユーザーに提供することが求められます。
コントロール目標 3: Sensitive Data Retention（機密データの保持）
未許可の機密データ開示を防ぐために、ソフトウェアが処理に必要な最小限の時間だけ機密データを保持することを求めています。機密データにも分類があり、一時的と持続的の2種類があります。一時的というのは、アプリケーション処理の中でワークメモリ内に生成されて、利用後には安全に削除する必要のあるデータです。持続的というのは、あとで使うためにディスクや不揮発性メモリに保存されるデータなどで、強力な暗号化もしくは同等の保護方法が必要とされます。
コントロール目標 4: Critical Asset Protection（重要な資産の保護）
ソフトウェアの設計を基に攻撃可能なシナリオを識別し、それに対応するセキュリティ対策の実装を求めています。今までのPA-DSSでは一般的なコーディングの脆弱性観点が挙げられ、それに対応するセキュア・コーディングの実践を求めていましたが、新しい基準ではこのようなパッケージ型の対策ではなく、個々のソフトウェアの設計ベースで必要な対策を組み立てることを重視している点からも、これまでのアプローチとの違いが見られます。
コントロール目標 5: Authentication and Access Control（認証とアクセス制御）
ここでは、重要な資産へのアクセス認証を求めていますが、この「重要な資産」はコントロール目標 1で識別したものを指しています。この認証に関して、パスワードの桁数など具体的な要件がなくなっています。ベンダ自身で、ユースケースや導入シナリオに応じて、十分に強固な認証手段であることを評価し、その根拠を文書化する必要があります。その根拠とする、業界のベストプラクティスとしては、NIST SP800-63-3およびSP800-63Bが挙げられています。これまでパスワードの定期的な変更の必要性については様々な議論があり、これまでPCI DSSやPA-DSSでは定期的な変更を求めていますが、このSP800-63Bでは、パスワードの侵害時やユーザーの変更依頼時を除きパスワード変更を求めるべきではないとしています。Secure Software Standardは、PCI DSSに先んじてベストプラクティスのほうに合わせてきているということでしょう。
コントロール目標 6: Sensitive Data Protection（機密データの保護）
機密データの保存時および伝送時の暗号化等による保護を求めるものです。ここで特徴的なのは、今までPCI DSS、PA-DSSでは、カード会員データ伝送時の暗号化については、オープンな公共ネットワークに伝送するときという条件付きでの要件でした。この条件がなくなったので、内部のLANだけで流通するような、カード会員データも伝送時の暗号化の対象になることが大きなポイントだと思います。
コントロール目標 7: Use of Cryptography（暗号の利用）
暗号化アルゴリズムや鍵管理プロセスについて、業界標準やベストプラクティスに基づいた実装を求めるもので、暗号化強度が引き上げられました。暗号のビット強度という考え方があり、少なくとも128ビット強度以上が必要となります。これが実際にどういうアルゴリズムと鍵長の組み合わせになるかというと、AESが128ビット以上、RSAであれば3,072ビット以上、ECCは256ビット以上必要となり、今までより一段上のレベルになっています。なお、3-Key TDES（トリプルデス）は、鍵長が168ビットですが、ビット強度で言うと112ビットとなるので実質使えないことになります。暗号化アルゴリズム・鍵長の移行に関する推奨事項を定めたNIST SP800-131A Rev.2でも、TDES（トリプルデス）は、2023年より後には使えないようになりましたので、おそらくそこが反映されたのかと思います。
コントロール目標 8: Activity Tracking（活動の追跡）
今までロギングと言っていたのが、トラッキングという名前に変わりました。記録する対象のイベントについては大きな変更はありませんが、記録そのものの完全性を維持するための実装が追加されています。
コントロール目標 9: Attack Detection（攻撃の検知）
攻撃の検知については、機能面での追加が必要になってくるところがあります。今まで、ログをベースに分析して攻撃を検知するのは運用の範疇なので、PA-DSSではログを出すところまで実装し、あとはそのログをベースに攻撃を検知するのはPCI DSSの範疇という整理でしたが、攻撃を検知するような機能を自らソフトウェア自身に組み込むことが必要になっています。これは、難易度が高いかもしれません。
コントロール目標 10: Threat and Vulnerability Management（脅威と脆弱性の管理）
プラットフォームやプロトコル、プログラミング言語レベルでの一般的な攻撃手法の識別・評価を行い、攻撃ルートが存在する場合は対策を実施し、リリース前の脆弱性テストと見つかった問題の修正を求めています。前出のコントロール目標 4では、攻撃シナリオの識別と緩和策の実装が求められましたが、ここではそのテストを実施するという関係性があります。
コントロール目標 11: Secure Software Updates（安全なソフトウェアの更新）
脆弱性を修正するアップデートを適切なタイミングで提供すること、アップデートは完全性を保証する安全な方法で配布することなど、PA-DSSの要件とほぼ同じです。
コントロール目標 12: Vendor Security Guidance（ベンダセキュリティガイダンス）
PA-DSSでは「PA-DSS実装ガイド」と呼んでいたものが、「ベンダセキュリティガイダンス」に名称が変わりました。文書の役割は同じで、セキュリティの観点で正しい導入ができるように提供するユーザー向けのガイダンスです。
コントロール目標 A.1: Sensitive Authentication Data（機密認証データ）、
コントロール目標 A.2: Cardholder Data Protection（カード会員データの保護）
Module Aを構成する2つのコントロール目標で、機密認証データ、カード会員データを扱う場合には対象になります。カード会員データの定義やそれに対する対策については今までと大きく変わりはありませんが、1点影響がありそうな点としては、今までPANを読み取り不能にする技術的な対策としては、トランケーション、トークナイゼーション、暗号化、あるいはワンウェイ・ハッシュというのも選択肢にありましたが、ワンウェイ・ハッシュが選択肢からなくなっているので、今後使えなくなると考えたほうが良いでしょう。
PCI Secure Software Lifecycle (Secure SLC) Standard の概要は？
基本的には、ソフトウェアのテスト、変更管理、脆弱性管理、リスク管理、ガイダンス提供など、いわゆるソフトウェア・ライフサイクルに関するものが対象になっており、この対象範囲についてはPA-DSSのときと大きくは変わっていません。
基準の中で、サードパーティ・サービスプロバイダ（TPSP）についての補足がありますが、これはSecure SLCに関連する業務を外部委託する場合の管理についてです。PCI DSSでもTPSPの評価については、TPSP自身が独立した審査を受けるか、あるいはTPSPのユーザー毎の審査の中で評価を受けるか、選択肢がありますが、それと考え方は同じです。
Secure SLC Standardは、10のコントロール目標とそれを4つにグルーピングしたセキュリティ目標で構成されています。ここでは、セキュリティ目標単位で概要を簡単にご紹介します。
Software Security Governance（ソフトウェアセキュリティのガバナンス）
Secure SLC Standard自体が、製品単位ではなく、ベンダ単位で認定す
また、ソフトウェアセキュリティのポリシーと戦略に関するコントロール目標では、ベンダとしてのソフトウェアセキュリティの戦略策定からそのパフォーマンスのモニタリングまでが要求されるという、今までのPA-DSSにはなかったレベルの話が出てきています。
Secure Software Engineering（安全なソフトウェアエンジニアリング）
脅威分析、脆弱性管理に関するものです。これはPA-DSSにも同様の要件がありますが、よりきめ細かい内容になっています。Secure Software Standardと同様に、重要な資産の識別という要件が入ってきています。
Secure Software and Data Management（安全なソフトウェアとデータの管理）
変更管理、バージョン管理、ソースコード・レポジトリの管理、機密データ管理に関するものです。機密データの管理では、トラブルシューティングなどで、ユーザーのログ情報を借用して持ち帰ったりしたときに、それを安全に扱う管理に関して定めています。いずれも今までのPA-DSSにもあった観点なので、大きな影響はないでしょう。
Security Communications（セキュリティに関する情報伝達）
ベンダとしての、ユーザーとのコミュニケーションに関わるものです。ベンダセキュリティガイダンスの提供および管理、製品のセキュリティやアップデートに関する情報提供などが該当します。セキュリティガイダンスに関する要件は、Secure Software Standardにもありますが、セキュリティガイダンスの内容自体はSecure Software Standardの方で評価して、その作成・提供・維持のプロセスに関してはSecure SLC Standardの方で評価するという整理になっています。
2019年中頃に認定プログラムが発表、移行期間は3年間
Software Security Frameworkに含まれる2つの基準を紹介しました。PA-DSSとの大きな相違点として、認定対象ソフトウェアと保護対象データが広がった点が挙げられます。今までPA-DSSで対象外だったクラウドやモバイルのソフトウェアも対象になってくるということと、アカウントデータ以外についても保護対象とするデータが出てきたことについて紹介しました。
そして、Objective-based Approachという新しい考え方に基づいて策定されたことも、大きなポイントです。新しいアプローチの考え方として、お仕着せの対策をそのまま実装するというよりは、個々のソフトウェアのリスク評価に基づいた対策が求められるようになっています。これは、今後ほかのPCIの基準にも適用されていくようですので、対策の考え方を大きく変えなければいけない面が出てくると思います。
今後のスケジュールとしては、認定プログラムが2019年中頃にリリースされる予定で、それに伴って既存のPA-DSSからの移行が開始されます。2022年10月が現行のバージョン3.2のPA-DSS認定アプリケーションの失効期限となりますので、そこに至るまでに3年ほどかけて移行していくことになります。
新規のPA-DSSの認定審査は、2020年中頃まで受け付けられます。それ以降は、新しいソフトウェアセキュリティ基準で対応していかなくてはいけないということになります。
当社としては、新基準に移行するまでのPA-DSS認定審査と、移行後の新しい審査資格でのソフトウェア認定審査も対応していく予定です。
※本内容は、2019年3月13日に開催された「ペイメントカー
お問い合わせ先
■NTTデータ先端技術株式会社
セキュリティ事業部
〒104-0052 東京都中央区月島1-15-7
パシフィックマークス月島7F
TEL：03-5859-5422
URL：http://www.intellilink.co.jp
お問い合わせフォーム
Email：sec-info@intellilink.co.jp
