コンプライアンスとポリシー

コンプライアンスとポリシー・レベル1

コンプライアンスとポリシーの目的は、PCI DSSやHIPAAなどのコンプライアンス分野の統制を識別することであり、COTSソフトウェア・リスクを制御するサービス品質保証契約(SLA)などの契約統制を作成したり、組織的なソフトウェア・セキュリティ・ポリシーを規定したり、そのポリシーと照合した監査を行ったりします。

[CP1.1: 81] 規制からの圧力を統合している。

企業またはその顧客が、米国のPCIデータ・セキュリティ・スタンダード、GLBA、SOX、HIPAA、およびEUのGDPRなどの規制またはコンプライアンス推進機関からの要件に適用する必要がある場合は、SSGは、ソフトウェアに対する制約を理解する窓口として機能します。SSGは、重複するコンプライアンス要件から発生する冗長や競合を排除する統合された方法を策定または協働で実施することも可能です。公式の方法を策定することで、適用可能な規制部分を、組織の適用方法を説明するコントロール・ステートメントに適用することができます。または、SSG以外の法的または他のリスクおよびコンプライアンス団体によって実行される既存のビジネス・プロセスも、規制の窓口の役割を果たせます。統一されたソフトウェア・セキュリティ・ガイダンスがあれば、規制圧力に対応するためのコンプライアンス作業をできるだけ効率的に遂行できます。企業によっては、規制環境に影響を与えるために新しいテクノロジーと規制を検討する標準団体と直接かかわって進めていく場合もあります。

[CP1.2: 105] PII義務を特定する。

SSGは、この情報を使用してプライバシーに関連するベスト・プラクティスを推進することにより、規制や顧客の期待から発生するPII義務の特定と説明において重要な役割を果たします。ソフトウェアがPIIを処理する方法は、明示的に規制を受ける可能性がありますが、そうでない場合もプライバシーは注目の集まる分野です。たとえば、組織がクレジットカードを処理している場合、SSGは、PCI DSSがカード保有者データの処理に加える制約を特定し、すべての関係者に通知する作業を支援します。ホスト環境をアウトソース(クラウドなど)している場合もPII義務からは免除されず、むしろ関連するすべての義務を把握することがますます困難になる可能性がある点に注意してください。また、PIIを処理するソフトウェア製品を開発する(PIIを直接処理するとは限りません)企業は、プライバシー制御とガイダンスを顧客に提供することによってこの要件に対応できます。消費者のプライバシー保護に対する期待が高まる中で、「ソフトウェアがいたるところに」拡散している状況とデータのスクレイピングや相関関係(ソーシャルメディアなど)によってPII保護にさらに新しい次元が加わっています。

[CP1.3: 76] ポリシーを作成している。

SSGは、内部、規制、および顧客主導のセキュリティ要件に適合するソフトウェア・セキュリティ・ポリシーの作成と、ポリシーへの貢献によって、組織全体を先導します。このポリシーには、ガバナンス・レベルの(多くの場合、多数の)セキュリティ推進団体に適合する統合された手法が含まれます。この結果、プロジェクト・チームは、すべての適用法令に適合するための詳細情報を知っている必要がなくなります。同様に、プロジェクト・チームは、顧客のセキュリティ要件を収集し続ける必要がなくなります。SSGポリシー文書は、PIIの処理や、暗号化の使用などの主要なコンプライアンス分野を中心に作成されている場合もあります。また、SSDLや、企業内でのその使用に直接関連することもあります。IoT、クラウド、モバイル・アーキテクチャなど新技術に関する意思決定を体型化することで、ポリシーの策定に対する関心が再燃する可能性もあります。同様に、たとえば、CI/CDや継続的なデプロイメント・パイプラインに自動化できるものとできないものを説明する必要がある場合もあります([SM3.4 ソフトウェア・デファインド・ライフサイクルのガバナンスを統合する]を参照)。アーキテクチャ標準とコーディング・ガイドラインはポリシーには含まれませんが、特定のカテゴリーのアプリケーションにコーディング・ガイドラインとアーキテクチャ標準の使用を規定し、強制することは、ポリシーに含まれます。ポリシーは、イニシアチブ・レベルで許容および拒否されるものを指します。強制的でないものは、ポリシーではありません。多くの場合、ポリシー文書は自動化してソフトウェア・デファインド・ライフサイクルで使用できるようにする必要があります。ポリシーは単に人が適用するプロセスとしてではなく、自動化して強制する必要があります。  

コンプライアンスとポリシー・レベル2

[CP2.1: 48] PIIインベントリを特定する。

組織は、各システムおよびそのシステムに関連するデータ・レポジトリによって処理または保存されるPIIの種類を識別します。PIIインベントリは、各アプリケーションに対してPIIの使用方法を示す方法と特定のタイプのPIIに対してそのPIIにアクセスするアプリケーションを示す方法の2つの方法で作成できます。PIIがクラウドベースのサービスやエンドポイントデバイスのエコシステムに流入し、そこ(コンテンツ配信ネットワーク、ソーシャルネットワーク、モバイルデバイス、IoTデバイスなど)に保存されるようにシステムアーキテクチャが進化していることにより、正確なPIIインベントリの維持が難しくなっています。インベントリは、侵害された場合に顧客への通知を必要とするデータベースのリストや危機シミュレーションで使用するリストを作成するなど、重大な状況で簡単に参照できるようにする必要があります([CMVM3.3 ソフトウェア・クライシスをシミュレートする。]を参照)。

[CP2.2: 47] コンプライアンス関連のリスクのためのセキュリティ・サインオフが要件となっている。

組織に、すべてのソフトウェア開発プロジェクトに対応する公式のコンプライアンス・リスク承認および説明責任プロセスが存在します。このプロセスにおいて、SSGはリスク承認者がリリース前のソフトウェアの状態を承認する際のアドバイザーの役割を果たします。たとえば、サインオフ・ポリシーでは、低減されていないコンプライアンスの問題や、対応していないコンプライアンスに関連するSSDL手順に、事業部長がサインオフすることを求める場合があります。サインオフは明示的で、後日参照できるよう保存する必要があり、高速のアジャイル・メソドロジーを使用している場合でも、例外はすべて追跡します。セキュリティ上の不具合のないアプリケーションでも、法規制に適合していない可能性があるため、クリーン・ペネトレーション・テストはコンプライアンス・サインオフの代わりにはなりません。DevOps組織のエンジニアがソフトウェアをリリースする技術的な能力を備え、承認基準が自動化に組み込まれている場合でも、意図的なリスク承認手順が必要です。リスク承認者が、自動化で実装される特定のコンプライアンス承認基準にサインオフする場合は、その基準が正確であり、自動化が実際に機能していることを継続的に検証する必要があります。

[CP2.3: 51] コンプライアンスのための統制を実装し、追跡している。

組織は、SSGによって作成された統制ステートメントにSSDLが従っていることによって適用要件への適合を示すことができます([CP1.1 規制圧力の統合]を参照)。SSGは、SDLCの統制を追跡し、問題領域に対処して、監査機関や規制機関が納得していることを確認します。組織のSDLCが予測可能で信頼性がある場合は、SSDLに従うことによって目的とするコンプライアンスの証拠が生成されるため、SSGは表立った動きをする必要がありません。プロセスにコンプライアンスの統制を組み込むDevOpsアプローチは、プロセスや手動による介在ではなく、ソフトウェア定義のインフラストラクチャやネットワークに見られることが多くなっています。これを適切に実行できている企業は、SSDLへの適合に関するコンプライアンスを達成できます。

[CP2.4: 44] すべてのベンダー契約のソフトウェア・セキュリティSLAが含まれている。

ベンダー契約に、ベンダーが組織のコンプライアンス事例やSSI(ソフトウェア・セキュリティ・イニシアチブ)に汚点を残さないことを保証するためのSLAが含まれています。新規の、または更新された契約に、ベンダーがソフトウェア・セキュリティ対策を実行し、組織のセキュリティ・ポリシーに適合した製品またはサービスを納品することを要件とする条項が含まれています([SR2.5 SLA文例集の作成]を参照)。オープン・ソース・ライセンスに関する条項からベンダー管理プロセスを開始できる場合もあります。これは、SLA内のソフトウェア・セキュリティに関する規則を規定する足がかりになります。ここでは従来のITセキュリティ要件や、ペネトレーション・テストを許可するのみの単純な合意では不十分です。

[CP2.5: 56] 上級幹部がコンプライアンスやプライバシー義務を確実に認識している。

SSGは、コンプライアンスおよびプライバシー対策に関する上級幹部からの支持を得るため、組織のコンプライアンスおよびプライバシー義務や、これらの義務に従わなかった場合起こりうる結果について、上級幹部にわかりやすい言葉で説明します。組織によっては、コンプライアンス違反やデータ漏洩によって発生する直接的な損害額や、副次的な影響を説明すると、この議題で討議を始める効果的な糸口になります。また、経営陣は組織内部の見解よりも外部の見解を重要視するため、外部の専門家が経営陣に説明すると有効な場合もあります。上級幹部からの適切な支持が得られているかどうかは、義務に従うためのリソースを十分に割り当ててくれることで確実にわかります。立ち上げの段階では有効ですが、データ漏洩が起こった直後の緊迫感は長くは続かないことに注意してください。

コンプライアンスとポリシー・レベル3

[CP3.1: 25] 規制コンプライアンスの事例がある。

SSGは、規制機関が必要とする情報を備えているため、ポリシーや統制を文書化し、SSDLから事実関係を収集しておくことにより、監査があるごとに予行演習したり、書類を大急ぎで揃えなくても組織のコンプライアンス事例を提示することができます。多くの場合、さまざまなツールから直接生成された同じ種類の報告書を使って、規制機関、監査機関、上級幹部を納得させることができます。場合によっては、ベンダの管理が組織のコンプライアンス・ニーズ (特にマルチクラウド展開の場合のクラウド・プロバイダーなど) をサポートする方法に関するベンダーからの追加情報が必要になります。多くの場合、異種のソースから取得される情報を正規化する必要があります。一般に、行動の最大の規制者は政府ですが、それ以外にも規制は存在します。 

[CP3.2: 15] ベンダーにポリシーを強制的に実行させている。

ベンダーには、社内で使用されているものと同じポリシーに従うこと、およびベンダーのセキュリティ対策がポリシーに適合していることを示す証拠を提出することが求められます。組織によっては、クラウド・プロバイダー、ミドルウェア・プロバイダー、仮想化プロバイダー、コンテナおよびオーケストレーション・プロバイダー、注文ソフトウェア開発者、請負業者などのさまざまなベンダーが存在し、それぞれが異なるポリシー要件に従う場合があります。コンプライアンスの証拠には、コード・レビューやペネトレーション・テストの結果、または自動化やインフラストラクチャに直接組み込まれたテストの結果を含めることができます。ベンダーは、特定のSSDLプロセスを実行していることを証明できます。BSIMMスコアやBSIMMscスコアを使用して、ベンダーが企業のソフトウェア・セキュリティ・ポリシーに適合していることを証明できる場合もあります。

[CP3.3: 7] ソフトウェア・ライフサイクル・データからのフィードバックをポリシーに返している。

過去の不具合を特定したり、不具合の発生そのものを防止するために、ソフトウェア・ライフサイクルからの情報が常にポリシー策定プロセスに返されています。これにより、情報がSSDLの障害傾向にマッピングされ、盲点を排除できます。不適切なアーキテクチャ解析、脆弱性の再発、セキュリティ・ゲートの無視、またはペネトレーション・テストを実行する会社の選択の誤りが定期的に発生する場合、ポリシーの弱点が露呈している可能性があります。たとえば、過剰に画一的なポリシーの実施により、エンジニアリング・チームが決められたデリバリー周期を守れないという摩擦が生まれていることがライフサイクル・データによって示されている場合もあります。急速な技術の進化によって、対処しなければならないポリシーにギャップが生じる場合もあります。長期的に見て、ポリシーは、より実践的で実行しやすいものに改善されていきます([SM1.1 必要に応じて公開プロセスが変化している]を参照)。最終的には、ポリシーは、SSDLデータによって洗練され、企業の有効性を改善します。