PCI DSSv4.0を読む⑨ 要件6の変更概要

PCI DSSv4.0が3月31日（日本時間の4月1日）にリリースされました。PCI DSSv3.0がリリースされたのは2013年12月でしたので、実に8年ぶりのメジャー改訂となります。

5/13に日本語版が1ヶ月少し遅れてリリースされました。英語版の360ページに比べて遥かに多い453ページの”大作”となっており、中々細部まで読むのが大変な基準書となっていますが、PCI DSSの専門家を自負している1人として、個人的な感想を交えて何回かに分けてv4.0について記事を書ければと思います。

※前回記事の6月から間が空いてしまいましたが、お盆休み期間に少し記事がかけたので公開します。

要件6：安全なシステムおよびソフトウェアの開発と維持

最初に、要件タイトルが変更されています。

ｖ3.2.1では、システムと「アプリケーション」が対象という書き方でしたが、

ｖ4.0では、システムと『ソフトウェア』が対象とアプリケーションよりも範囲が広がった記載となっています。この変更により、（要件6.2を除き）全てのシステムコンポーネントに適応される事が明確となっています。

要件6における新要件は4つです。

最初は6.1.2の「役割と責任」に関する新要件です。他の章同様に担当及び責任者の役割を明確にする事が求められていますが、要件6に関してはほとんどの組織で従来と変わらない（あまり新規定の影響は無い）かと思います。

これは、要件6は開発系の要件でもあるので、従来から担当や開発責任者等が明確になっている事が多かった事によるものです。1点留意すべきなのが、6.1.2.ｂにある「役割と責任が文書化」で、文書化要求がある点です。

v3.2.1ではここに充当すると思われる要件12.4があり、要件12.4に従って定義を”真面目に対応”していた組織では特に問題は無いのかと思いますが、そうでも無かった所は、6.1.2.bに応じた文書を準備する事が必要となるかと思います。

2つ目の新要件は6.3.2、特注ソフトウェア及びカスタムソフトウェアのリスト（インベントリ）維持の規定です。

規定を見ると特注ソフトウェアやカスタムソフトウェアに含まれているサードパーティコンポーネントの脆弱性がきちんと管理されてない状態を防ぐ為に、きちんとリスト化して管理（維持）する事が求められています。

去年~今年にかけて話題となった『Log4Shell』（Log4J）を思い浮かべると分かりやすいかも知れません。独自システム開発では完全にスクラッチでソフトウェアを開発する事は稀で、サードパーティのコンポーネントを利用して開発するケースが多いかと思います。ソフトウェア部品の脆弱性はいつ出てくるか分かりませんが、危険な脆弱性が出た際に迅速に対応できる様に、ライブラリ、APIなどを含みリスト化し維持・管理する事は非常に重要です。

※最近ソフトウェアサプライチェーン攻撃への対策としてソフトウェア部品表：SBOM（Software Bill Of Materials）が注目されていますが、PCI DSS要件もこの考え方が取り入れられたものと思われます。

規模の大きいシステムをいくつも稼働させている組織には、この要件はかなり調査に手間がかかるものになるかも知れません。その為に、2025年3月31日の未来日付が設定されているのだと思いますが、この規定に関してはカスタマイズドアプローチで「既知の脆弱性の悪用が出来ない状態」を作り出す事にチャレンジする組織も、今後出てくる気がします。

※Moving Target Defenseの考え方で、カスタマイズドアプローチ要件を満たせる可能性を感じます。

3つ目の新要件は6.4.2、公開Webアプリケーションに対するWebベースの攻撃を継続的に検出し、防止する自動化された技術ソリューションを展開するための新要件です。