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

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

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

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

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

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

ソフトウェアが個人識別情報(PII)を処理する方法は、明示的に規制を受ける可能性がありますが、そうでない場合もプライバシーは注目の集まる分野です。SSGは、規制や顧客の期待から発生するPII義務の特定と説明において重要な役割を果たします。SSGはこの情報を使用してプライバシーに関連するベスト・プラクティスを推進します。たとえば、組織がクレジットカードを処理している場合、SSGは、PCI DSSがカード保有者データの処理に加える制約を特定し、すべての関係者に通知します。ホスト環境をアウトソース(クラウドなど)している場合もPII義務からは免除されない点に注意してください。また、PIIを処理するソフトウェア製品を開発する(PIIを直接処理するとは限りません)企業は、プライバシー制御とガイダンスを顧客に提供していることを認められます。IoTとモバイル・デバイスの普及により、PII保護にまたもう一つの次元が追加されました。

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

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

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

[CP2.1: 39] PIIデータ・インベントリを特定する。

組織は、モバイルおよびクラウド環境を含む、各システムおよびデータ・レポジトリによって処理または保存されるPIIの種類を識別します。PIIインベントリは、各アプリケーションがそのPIIの使用方法を示す方法か、または特定のタイプのPIIとアプリケーションにPIIとアプリケーションの接触を限定するかの2つの方法で作成できます。いずれの場合も、データ・レポジトリのインベントリが必要です。複数のデプロイメント環境にわたってアプリケーションが分散している場合、PIIインベントリの管理は複雑になり、これに対処する必要があります。常に発展するPIIの定義にも対処する必要があります。このインベントリは、組織のPII義務と組み合わせれば、プライバシー計画の基盤になります。たとえば、SSGは、データが漏洩した場合に顧客に通知する必要があるデータベースのリストを作成できます。

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

組織に、開発メソドロジーに関係なく、すべてのソフトウェア開発プロジェクトに対応する公式のコンプライアンス・リスク承認および説明責任プロセスが存在します。SSGは、リスク承認者がリリース前のソフトウェアの状態を承認する際のアドバイザーの役割を果たすことができます。たとえば、サインオフ・ポリシーでは、低減されていないコンプライアンスの問題や、対応していないコンプライアンスに関連するSSDL手順に、事業部長がサインオフすることを求める場合があります。サインオフは明示的で、後日参照できるよう保存する必要があります。高速のアジャイル・メソドロジーを使用している場合でも、例外はすべて追跡します。セキュリティ上の不具合のないアプリケーションでも、法規制に適合していない可能性があります。

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

組織は、SSGによって作成された統制ステートメントにSSDLが従っていることによって適用規制への適合を示すことができます([CP1.1 規制圧力の統合]を参照)。SSGは、統制を追跡し、問題領域を誘導し、監査機関や規制機関が納得していることを確認します。組織のSDLCが予想可能で信頼性がある場合は、SSGは、主に記録係として機能し事態を静観できます。SDLCが不均一であったり、信頼性が低い場合、またはサポートしているインフラストラクチャより迅速な対応を試みる場合(CI/CDなど)は、SSGは単なる評価係としてではなく、より積極的に行動する必要があります。これを適切に実行できている企業は、SSDLへの適合に関するコンプライアンスを達成できます。

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

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

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

SSGが、コンプライアンスやプライバシーに関するアクティビティについて、上級幹部から合意を取り付けています。上級幹部は、組織のコンプライアンスおよびプライバシー義務や、これらの義務に従わなかった場合起こりうる結果について、わかりやすい言葉で説明を受けています。組織によっては、コンプライアンス違反やデータ漏洩によって発生する直接的な損害額や、副次的な影響を説明すると、この議題で討議を始める効果的な糸口になります。また、経営陣は組織内部の見解よりも外部の見解を重要視するため、外部の専門家が経営陣に説明すると有効な場合もあります。上級幹部が正しく認識しているかどうかは、業務を実行するためのリソースを十分に割り当ててくれることで確実にわかります。データ漏洩が起こった直後にこの問題が注目され討議されても、長くは続かないことに注意してください。

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

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

SSGは、規制機関が要求する情報を準備しています。ポリシーや統制を文書化し、SSDLから事実関係を収集しているため、SSGは、監査があるごとに予行演習したり、書類を大急ぎで揃えなくても組織のコンプライアンス事例を提示することができます。場合によって、さまざまなツールから直接生成された同じ種類の報告書を使って、規制機関、監査機関、上級幹部をすべて納得させることができます。

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

ベンダーには、社内で使用されているものと同じポリシーに従うこと、およびベンダーのセキュリティ対策がポリシーに適合していることを示す証拠を提出することが求められます。これは、クラウドおよびモバイル・プラットフォーム・プロバイダーにも適用されます。証拠には、コード・レビューやペネトレーション・テストの結果が含まれます。ベンダーは、特定のSSDLプロセスを実行していることを証明することもできます。BSIMMスコアやvBSIMMスコアを使用して、ベンダーが企業のポリシーに適合していることを証明できる場合もあります。

[CP3.3: 5] SSDLデータからのフィードバックをポリシーに返している。

過去の不具合を特定したり、不具合の発生そのものを防止するために、SSDLからの情報が常にポリシー策定プロセスに返されています。SSDLの障害傾向のために起こる盲点が排除されます。たとえば、不適切なアーキテクチャ解析、脆弱性の再発、セキュリティ・ゲートの無視、またはペネトレーション・テストを実行する会社の選択を誤った場合などにポリシーの弱点が露出します。同様に、過度の官僚性を強制するポリシーも、アジャイル・メソドロジーに適切なものに調整する必要があります。長期的に見て、ポリシーは、より実践的で実行しやすいものに改善されていきます([SM1.1 必要に応じて公開プロセス(役割、責任、計画)が変化している]参照)。最終的には、ポリシーは、SSDLデータと連携し、企業の有効性を改善します。