PCI DSS 4.0の準拠に向けて
~Parasoft Jtestの活用案をご紹介~

2022年3月にPCI DSSは新しくv4.0へバージョンアップされました。
それにより、新しいバージョンの認定取得に向けた準備や対策が必要になるかと思います。

※ 前バージョンのPCI DSS v3.2.1は2024年3月31日に廃止予定

本記事では、PCI DSS4.0の準拠に向けて、Parasoft Jtest(以降 Jtest)を使ったの活用案をご紹介します。

目次

 

PCI DSSとは

PCI DSS(Payment Card Industry Data Security Standard)は、クレジットカード、デビットカード、およびキャッシュカード等のトランザクションのセキュリティを強化し、カード所有者の個人情報や取引情報の悪用から保護するために策定されました。これは、カードのセキュリティインシデントとプライバシーの脅威に対する防止、検出、および適切な対応を含む、堅牢なペイメントカードのデータセキュリティプロセスの開発に必要な実用的なコーディングフレームワークです。PCI DSSは、ペイメントカード情報を安全に使用するために不可欠な12の要件で構成されており、特に要件6は、ソフトウェア開発プロセスにおける一般的なコーディングの脆弱性へ対処することに重点を置いています。

主なPCI DSS要件
安全なネットワークとシステムの構築と維持 1. ネットワークセキュリティコントロールの導入と維持
2. すべてのシステムコンポーネントにセキュアな設定を適用する
アカウントデータの保護 3. 保存されたアカウントデータの保護
4. オープンな公共ネットワークでの送信時に強力な暗号化技術でカード会員データを保護する
脆弱性管理プログラムの維持 5. 悪意のあるソフトウェアからすべてのシステムおよびネットワークを保護する
6. 安全なシステムおよびソフトウェアの開発と維持
強力なアクセス制御手法の導入 7. システムコンポーネントおよびカード会員データへのアクセスを、業務上必要な適用範囲(Need to Know)によって制限する
8. ユーザーの識別とシステムコンポーネントへのアクセスの認証
9. カード会員データへの物理アクセスを制限する
ネットワークの定期的な監視およびテスト 10. システムコンポーネントおよびカード会員データへのすべてのアクセスをログに記録し、監視すること
11. システムおよびネットワークのセキュリティを定期的にテストする
情報セキュリティポリシーの維持 12. 組織の方針とプログラムによって情報セキュリティをサポートする

 

Jtestはどのように活用できる?

Jtestは、IDEやコマンドライン(ビルドツールやCI/CDプロセス等)を介してJavaコードに対して静的解析を実行することができます。Jtestには、PCI DSSの要件6.2.4を満たす「PCI DSS v4.0用のルールセット」が実装されているため、PCI DSSに準拠したソフトウェア脆弱性の早期検出と改修に活用できます。

セクション
6.1 安全なシステムおよびソフトウェアを開発・維持するためのプロセスおよび仕組みが定義され、理解されている。
6.2 特注ソフトウェアおよびカスタムメイドのソフトウェアは安全に開発されている。
 ・ 6.2の各セクション(要件の詳細は省略)
    -  6.2.1:開発プロセスの定義に関する要件
    -  6.2.2:セキュリティ知識のトレーニングに関する要件
    -  6.2.3:実稼働または顧客へリリースする前のレビューに関する要件
    -  6.2.4:ソフトウェア攻撃や関連する脆弱性を防止・軽減するための技術的な対策に関する要件
6.3 セキュリティの脆弱性を特定し、対処している。
6.4 一般公開されているウェブ アプリケーションは、攻撃から保護されている。
6.5 すべてのシステムコンポーネントの変更が安全に管理されている。

  

Jtestでは、要件6.2.4を5つのカテゴリに分けて問題を管理しています。(以下表を参照)

Parasoft Jtestがサポートする問題の内容(一部解析ルールを抜粋)
PCI DSSカテゴリ Parasoft Jtest ルール
6.2.4.1 インジェクション攻撃
(SQL、LDAP、XPath、コマンド、パラメータ等の欠陥への攻撃)
 – 未検証の入力を配列インデックスとして使用しない
 – Seam Logging API を使用しメッセージをログに記録する場合、信頼されていない入力を使用しない
 – コマンド インジェクションから防御する
 – Jakarta Digester インジェクションから防御する
 – 環境に対するインジェクションから防御する
 – ファイル名に対するインジェクションから防御する
 – フォーマット文字列からサニタイズされていないユーザー入力を除外する
 – JXPath インジェクションから防御する
 – LDAP インジェクションから防御する
 – ログ偽造から防御する
 – ネットワーク リソース インジェクションから防御する
 – Reflection インジェクションから防御する
 – SQL インジェクションから防御する
 – XML データ インジェクションから防御する
 – XPath インジェクションから防御する
 – createStatement ではなく prepareCall または prepareStatement を使用する
 – XPath クエリーの評価での XPath インジェクションを防ぐ
6.2.4.2 データおよびデータ構造に対する攻撃
(バッファー、ポインタ、入力データ、共有データ等への攻撃)
 – 配列の境界を超えてアクセスしてはならない
 – 共有の静的データを保護するためにインスタンス ロックを使用しない
 – 単一バイト ストリームまたは文字ストリームに複数のバッファー付きラッパーを作成してはならない
 – メモリ割り当サイズの決定に使用する前に、汚染されている可能性があるデータを検証する
 – ファイル名に対するインジェクションから防御する
 – フォーマット文字列からサニタイズされていないユーザー入力を除外する
 – ネットワーク リソース インジェクションから防御する
6.2.4.3暗号の使用に関する攻撃
(暗号実装、アルゴリズム、暗号スイート等への攻撃)
 – Spring でのデータ暗号化で、セキュアではない暗号化アルゴリズムを使用しない
 – ハード コーディングされた暗号化キーの使用を避ける
 – 安全でないアルゴリズムを暗号化のために使用しない
 – ハッシュ関数は salt とともに使用する
 – 機密データを cookie にプレーンテキストで格納してはならない
 – パスワードがプレーンテキストとして格納されず、十分な長さがあることを確認する
 – java.util.Random または Math.random() の代わりに java.security.SecureRandom を使用する
6.2.4.4 ビジネスロジックに対する攻撃
(API、通信プロトコル、チャンネル、他システム等への攻撃、XSS、CSRF等)
 – 検証の前にすべてのデータを正規化する
 – 危険なメソッドの引数を検証メソッドでカプセル化する
 – cookie を HttpOnly としてマークする
 – 機密データの公開を防止する
 – HTTP レスポンス分割から防御する
 – XSS の脆弱性の可能性から防御する
 – スクリプティング API の使用を検査する
6.2.4.5 アクセス制御の仕組みに対する攻撃
(識別、認証、認可等の仕組みへの攻撃)
 – 意思決定のための DNS ルックアップを避ける
 – web.xml ファイルに複数のセキュリティ ロールを同じ名前で定義しない
 – LoginContext.login() の前に必ず HttpSession.invalidate() を呼び出すこと
 – セキュリティ アノテーションのない EJB 3 メソッドを避ける
 – 適切なセッション有効期限を確認する
 – ‘web.xml’ ファイルでセッションがタイム アウトするよう設定されていることを確認する
 – getSecure() および setSecure() メソッドを使ってセキュアな Cookie の使用を推進する

※ 上記は 『PCI DSS v4.0』 の脆弱性の一部を検出するためのルールです。ルールの利用により全ての脆弱性を検出できるわけではありません。

 

Jtestの静的解析機能をご紹介

早速、Eclipseで開発中のソースコードに対して、Parasoft JtestでPCI DSS用の静的解析を実行して検出された違反の中から「要件6.2.4のSQLインジェクションに関する違反を確認する」流れの一例をご紹介します。

1.Eclipse上で Jtestを実行し、静的解析違反を検出すると、以下のようにEclipseの専用のビュー上に検出された違反の一覧が表示されます。

※今回は、赤枠(要件6.2.4のSQLインジェクションに関する違反)を選択し、詳細を確認します。アプリケーションにこの脆弱性が存在する場合、攻撃者はアプリケーションが想定していない SQL 文や OS コマンドを実行させ、不正操作によるデータの取得、改ざん、削除やDB の破壊、不正なシステム操作を行うことができます。

2.検出された違反を選択すると、以下のように違反の詳細を確認することができます。

※ 静的解析のフロー解析用のルールで違反が検出されると以下のように、ソースのフローが分析され、違反の起点と違反箇所が表示されます。(Parasoft Jtestのフロー解析では複数のクラスに跨った違反を検出することも可能)

3.「2.」の違反の詳細を選択(上記画像の赤枠)することで、実コード上から違反内容の確認と修正ができます。

※ 違反コード解説 ※

このコードでは、18 行目でWeb アプリケーションの画面でユーザーが入力したデータ(パスワード)を取得し、19 行目で SQL 文に直接内容を埋め込みます。攻撃者がパスワードとして ‘ or ”=’ を利用した場合、 21 行目で生成されるのは次のようなパスワードの認証を行わずにユーザー情報を取得することができる SQL 文です。

24 行目でこの SQL 文が実行された場合、正しい認証情報を入力していないのにも関わらず、攻撃者は任意のユーザーでアプリケーションの利用が可能になります。

4.解析結果は、HTMLファイルとしても出力できます。

 

5.他にも解析結果を専用のダッシュボードで管理することもできます。

※1. 静的解析結果を専用の管理ツール(Parasoft DTP)にインポートすることで、日々の違反数や対応状況等をブラウザ上で確認できます。

※2. 以下のように、Compliance Report:PCI DSSのCompliance Reportとして表示し、PDFに出力することもできるため、静的解析(PCI DSS)の検証結果としてご利用いただけます。

 

まとめ

PCI DSS v4.0へのバージョンアップに伴い、PCI DSSの新しい要件を準拠するためには、最初はある程度、工数を割く必要があります。PCI DSSの内容の理解や教育に掛ける工数も増えることでしょう。しかし、Jtestで今回ご紹介した機能を使い、PCI DSSの中でも特に重要な要件「6.2.4:ソフトウェア攻撃や関連する脆弱性を防止・軽減するための技術的な対策に関する要件」を準拠することで、PCI DSSのコンプライアンス達成へのコストを削減し、時間と労力の節約に役立てられます。

他にも、Jtestをお使いになればPCI DSSに準拠した「セキュリティ問題の対策の前倒し」「継続的なセキュリティ対策」が期待できるDevSecOpsへの導入にも活用できますので、ご興味がある方は試してみてはいかがでしょうか。

※本資料におけるPCI DSSの要件は、PCI SSC日本語サイトのドキュメント(PCI DSS)から引用
https://www.pcisecuritystandards.org/lang/ja-ja/

Parasoft Jtestについて

Java対応静的解析・単体テストツール Parasoft Jtest

Jtestは、テスト工数の大幅削減とセキュアで高品質なJavaシステムの開発を強力にサポートするJava対応テストツールです。2,000個以上のコーディング規約をもとにソースコードを静的に解析し、プログラムの問題点や処理フローに潜む検出困難なエラーを検出します。さらに、JUnitを用いた単体テストについて、作成、実行、テストカバレッジ分析、テスト資産の管理といった単体テストに係る作業をサポートし、単体テストの効率化を促進します。

Top