セキュアコーディングトレーニング、
PCI DSS 4.0.1 要件6.2.2に対応

監査人が実際に証拠として求めるもの

6.2.2を見るQSAは、3つの文書的な要素を求めます。1つ目は割り当て — 誰が対象範囲内にいて、何が割り当てられたか、そして役割からカリキュラムへのマッピングがどのように決定されたか。2つ目は修了 — 開発者ごとの記録、タイムスタンプ、スコアまたは合格ステータス、修了したコンテンツのバージョン付き。3つ目はコンテンツの最新性 — カリキュラムが現在の脆弱性クラスを反映していること、そして前回の評価以降に重要な更新が組み込まれている証拠。

チームレベルで年次の修了レポートを1つ生成するプログラムは苦労します。バージョンスタンプ付きのコンテンツ参照を含む学習者ごとの記録をエクスポートするプログラムはそうではありません。基準は、どれだけ多くのトレーニングを実施したかではありません。指名された開発者が、ローリング12か月ウィンドウ内で、指名されたコンテンツを完了したことをどれだけ明確に実証できるかです。

SecureCodingHubが12.6.1対6.2.2にどのようにマッピングされるか

これら2つの要件はよく混同されますが、混同すべきではありません。要件12.6.1は、すべての人員 — フィッシング、パスワード管理、物理的セキュリティ、インシデント報告 — を対象とした一般的なセキュリティ意識向上トレーニングです。対象者は、役割に関わらず、カード会員データまたはそれに触れるシステムへのアクセス権を持つすべての人です。要件6.2.2は、要件自体に指定された言語別、役割関連、実践的な特性を持つ、ソフトウェア開発人員専用のセキュアコーディングトレーニングです。

SecureCodingHubは6.2.2に対応します。単独で12.6.1を満たすものではなく、一般的な意識向上プラットフォームとしては販売していません。広範な対象者向けに12.6.1意識向上ベンダーを使用し、開発者向けにSecureCodingHubを使用するプログラムは、1つのツールが構築されていない作業を強制することなく、両方の要件をカバーします。

よくある範囲設定のミス

最も頻繁な範囲設定のエラーは、本番向けサービスを所有するエンジニアのみをトレーニングし、隣接するチームを除外することです。内部ツール、バッチジョブ、統合コード、またはカード会員データ環境に流れ込む共有ライブラリを書く開発者は、そのコードがその環境に影響を与えうる場合、依然として6.2.2の対象範囲内です。範囲は、エンジニアが組織図のどこに座っているかではなく、コードが触れるシステムによって決まります。

2つ目のミスは、契約社員や臨時のエンジニアリングスタッフを除外することです。契約社員がCDEで実行されるコードをコミットする場合、彼らは対象範囲内です。契約関係は要件を変更しません。クリーンなプログラムでは、従業員と契約社員を同じカリキュラム割り当てロジックでカバーする単一のロスターを持ちます。

3つ目は、トレーニングを年次イベントとして扱うことです。ローリング12か月の最新性ウィンドウは容赦ありません。評価の13か月前にカリキュラムを完了した開発者は、前年に完全にトレーニングされていたとしても、その評価サイクルでは非準拠です。トレーニングを年1回のキャンペーンとしてスケジュールするプログラムは、新入社員や役割変更で最新性から外れる傾向があります。12か月の境界での自動的な再トレーニングを伴う継続的な割り当てが、介入なしで2回目のサイクルを乗り切る唯一のパターンです。