OpenSSLバージョンが原因でPCIコンプライアンスエラーが発生する
AMI Linux（Amazon）にクライアントがあり、現在OpenSSL 1.0.1k-15.99を使用しています。
私が知る限り、Amazonはこのページのセキュリティパッチのバックポートに関して非常に優れています： https://alas.aws.Amazon.com/ そして、彼らは複数の場所で彼らが述べた実際には、このスレッドごとにそうし続けます： https://forums.aws.Amazon.com/thread.jspa?messageID=759633#7596
報告されたOpenSSLのバージョンが1.0.1kであるため、PCIコンプライアンススキャンがクライアントで失敗しました。これは、現在実行中のバージョンでパッチが適用されていることがわかっているCVEが多数リストされているためです。
残念ながら、スキャナーの方法論は非常に不透明であり、失敗の具体的な原因として直接的な答えを得ることができず、クレジットカードプロセッサーもスキャナーのテクニカルサポートも役に立たない。
ディストリビューションプロバイダーが、ベークしたバージョンにすべての関連するパッチをバックポートする場合、実際のセキュリティリスクはありますか？
PCI DSSセクション6.2の状態：
6.2該当するベンダー提供のセキュリティパッチをインストールして、すべてのシステムコンポーネントとソフトウェアが既知の脆弱性から保護されていることを確認します。リリース後1か月以内に重要なセキュリティパッチをインストールします。
OpenSSL 1.0.1k（毎週適用）へのパッチを含む、Amazonの最新パッチのインストールは、この要件を満たしていますか？または、AMIパッチの適用は「カウント」ではなく、実際の「ベンダー」からのOpenSSLが必要です。この場合は https://www.openssl.org/ ？
私はスキャナー/クレジットカードプロセッサーのPCIコンプライアンスチームにこれらすべての質問をしましたが、明確な回答（または実際にはまったく回答を受け取っていません-彼らは知らないようですサーバーの有効期限が切れたSSL証明書と古いバージョンのOpenSSL）の違い、そして私のクライアントは不快になっています。
これを改善するための標準的な手順は何ですか？たとえば、ソースからOpenSSLをコンパイルする能力には自信がありません。
クリーンスキャンを取得するか、PCI-QSAがコンプライアンスに準拠しているという証明を承認するまで、実際のセキュリティへの影響に関係なく、コンプライアンス要件を満たす責任はユーザーにあります。
コンプライアンスはセキュリティに等しくなく、セキュリティはコンプライアンスに等しくありません。
つまり、通常、組織は、スキャンで見つかった特定のCVEが特定のパッチ/アプリケーションのサブバージョンで対処されていることのベンダーの証明と、PCIゾーンのすべてのシステムにそのバージョンのコードが適用されていることの証明の両方を文書化します（修復が実際に何を伴うのかについて）。
QSAは、ASVスキャンの結果が実際には偽陽性であることを証明できます。
あなたの質問はまた別の問題につながっています：主要な既知の脆弱性があり、ベンダーがパッチを当てない場合はどうなりますか？この場合は、脆弱性に対処するために独自の修復方法を考え出す必要がある場合があります。あなたはまた、誰かがあなたのディストリビューションの最新バージョンはXであるかもしれないが、OpenSSL（またはここにアプリケーションを挿入）の最新バージョンはYであるかもしれないと主張するかもしれません。このシナリオでは、あなたはオペレーティングシステムのパッチに加えて、アプリケーションレベルのパッチを最新の状態に保つ責任があります。したがって、個々のパッケージを最新の状態にしないと、コンプライアンス違反になります。
OpenSSLのコンパイルごとに、それは特に難しくはないが、最初に（本番環境ではなく）別のシステムでテストすることになると思います。
最終的には、QSAに相談する必要があります（ある場合）、非常に具体的なガイダンスが提供される場合があるためです。 QSAが良いと、ここでも時間を節約できます。後で訴訟が発生した場合、カードプロセッサはあなたに助言したくないかもしれません。もう一度、あなたのQSAに尋ねてください。
厳密なセキュリティの観点から、すべてのコンプライアンスを無視します。常に攻撃面が最新のパッチリリースにしっかりとパッチされていることを確認し、可能な場合は、多層防御のための追加のコントロールを追加します。 Fail2Ban のようなツールがあなたの友達かもしれません。同様に、パッチを適用してもセキュリティの問題は解決されないことに注意してください。データを保護するには、追加の制御が本当に必要です。同様に、特定のコンプライアンス基準を満たすことは、優れたセキュリティアーキテクチャを提供しません。基本的なコンプライアンスガイドラインやベンダーのパッチレベルに対応するだけでなく、ソリューションの奥深くまでセキュリティを設計する必要があります。
あなたがデータ管理者であろうとデータ所有者であろうと、あなたはシステムがこのデータ（またはデータへのアクセス）を可能な限り安全に保護する責任を負うことに直接の責任があることに留意してください。パッチを当てるだけでは十分ではありません。
セキュリティとコンプライアンスは時々競合する目標です。残念なことに、これら2つは常に整合しているわけではなく、企業が費やしたお金が実際にあるものから奪われることは珍しいことではありませんデータを保護し、組織を「準拠」させることに費やしてもらいます（このプロセスはリスクを増大させることもあります）。これら2つの目標を混同しないように注意してください。 コンプライアンスの問題とセキュリティの問題があり、これらは同じものではありません。これらの2つの目標を分けておくと、優れたソリューションが生まれます両方を同じソリューションで毎回解決しようとする場合よりも簡単です。 1つのソリューションで両方を修正できるのは素晴らしいことですが、これは必ずしも希望どおりに行われるとは限りません。
最後に、ディストリビューションプロバイダーでもこれに対処してください。可能な場合はセキュリティパッチに遅れずについていくように彼らに圧力を加えることは、セキュリティ活動の優先順位付けに役立ちます。