標準と要件

標準と要件プラクティスには、組織からの明示的なセキュリティ要件の聞き取り、推奨するCOTSの決定、主なセキュリティ制御(認証、入力検証など)のための標準の構築、使用されているテクノロジーのセキュリティ標準の作成、標準審査委員会の設立などが含まれます。

標準と要件レベル1

[SR1.1: 75] セキュリティ標準の作成。

ソフトウェア・セキュリティはセキュリティ機能だけではありませんが、その実現には、セキュリティ機能が含まれます。SSGは、ポリシーに適合し、特定のセキュリティ中心の運用を行うための承認された方法を説明する標準を作成することによって、組織のセキュリティ・ガイダンス需要に適合します。標準では、たとえば、Androidデバイス上の認証の実行方法や、ソフトウェア・アップデートの信頼性を判断する方法について説明します([SFD1.1 セキュリティ機能の構築と公開] のSSGがセキュリティ標準の参照実装を行う例をご覧ください)。多くの場合、ソフトウェアに独自の標準は必要ありません。標準はさまざまな方法で展開できます。標準とガイドラインは開発環境で自動化できる場合があります(IDEに作り込むなど)が、ガイダンスをコード例やコンテナに明示的に結び付ければ、有効性が向上し、使用しやすくなります。広く採用、または実施されていない標準は、標準ではありません。

[SR1.2: 78] セキュリティ・ポータルの作成。

組織には、ソフトウェア・セキュリティに関する情報が収集されている、中央保管所があり、その存在が周知されています。通常、これはSSGが管理している内部Webサイトです。ここには、最新かつ最大量のセキュリティ標準や要件、SSGが提供した他のリソース(トレーニングなど)が保管されており、従業員はサイトにアクセスして参照できます。まれにしか変更されないガイドライン文書を掲載した静的ポータルより、インタラクティブ・ウィキの方が効果的です。組織は、メーリング・リストや対面会議でこれらの資料を補完できます。

[SR1.3: 76] コンプライアンス制約を要件に変換する。

コンプライアンス制約は、各プロジェクトのソフトウェア要件に変換されます。これは要件と共にコンプライアンス制約を明示的に表し、コンプライアンスが管理上のタスクであることを示す、組織のコンプライアンス戦略の根幹です。たとえば、組織で、クレジットカード取引を処理するソフトウェアを日常的に構築している場合は、要件フェーズのSSDLでPCI DSSコンプライアンスが重要な役割を果たします。他の場合では、国際互換性の目的で構築されたテクノロジー標準にはセキュリティ・ガイダンスが含まれます。これらの標準を要件として表すと、監査の際のトレーサビリティと可視性の提示に役立ちます。特に、再利用可能なコードやコンテナに要件をコード化する場合に有用です。  

標準と要件レベル2

[SR2.2: 38] 標準審査委員会の設立。

組織は、標準の規定に使用されるプロセスを公式化するための標準審査委員会を設立し、すべての関係者の意見が反映される機会を作ります。審査委員会を運営する場合には、提案された標準の支持者を任命します。支持者には、標準が目標を満たしていることを証明し、審査委員会から承認を得て委任される義務があります。企業のアーキテクチャまたは企業のリスク・グループに、標準審査委員会の設立や管理責任を委任できる場合もあります。

[SR2.3: 23] テクノロジー・スタックの標準を規定する。

組織は特定のテクノロジー・スタックを標準化します。グループは、新しいプロジェクトごとに新しいテクノロジー・リスクを調査しなくてもすむため、SSGの仕事量が軽減されます。スタックを安全に使用するために必要な仕事量が減るため、組織が、テクノロジー・スタックごとにセキュリティ上安全な基本構成を構築することが理想的です。スタックには、管理対象言語のオペレーティング・システム、データベース、アプリケーション・サーバー、ランタイム環境などが含まれます。スタックは、セキュリティの最先端領域に集まっています。現在、モバイル・テクノロジー・スタックおよびプラットフォームとクラウドベースのテクノロジー・スタックが、セキュリティに関する情報が集まっている分野です。  

[SR2.4: 39] オープンソースの特定。

オープンソースに伴うリスクを管理する第一歩は、ポートフォリオ全体で使用されているオープンソース・コンポーネントを特定し、依存関係をよく理解することです。脆弱性があることが知られている古いバージョンのコンポーネントや、同じコンポーネントの複数のバージョンが使用されていることが判明することは珍しくありません。コンポーネント全体、あるいは大量のコードの借用などのオープンソース・コンポーネントを特定するための自動化されたツールを使用することも、このアクティビティを実行するための一つの方法です。開発者が許可を申請するだけの非公式の年次審査やプロセスでは、十分な結果は得られません。次のレベルの成熟度では、このアクティビティは、オープンソースの使用を制限するポリシーによって組み込まれています。

[SR2.5: 29] SLA文例集の作成。

SSGは、法務部門と協力して、ベンダーやアウトソース・プロバイダー(クラウドプロバイダーを含む)にソフトウェア・セキュリティ対策を要求する契約で使用される、標準のSLA文例集を作成します。法務部門が文例集を理解していると、コンプライアンスやプライバシーの問題の防止にも役立ちます。ベンダーおよびアウトソース・プロバイダーは会社が規定したソフトウェア・セキュリティ標準に適合することが契約によって要件付けられます([CP2.4 すべてのベンダー契約にソフトウェア・セキュリティSLAを含める]を参照)。文例集の文言ではvBSIMM測定値やBSIMMスコアなどのソフトウェア・セキュリティ・ベンダー管理ソリューションを参照することもできます。

標準と要件レベル3

[SR3.1: 17] オープンソースのリスクを制御している。

組織は、オープンソース・コンポーネントを使用することに伴う脆弱性と、大量の依存関係への露出を制御します。オープンソースの使用は、事前定義されたプロジェクト、またはSSGセキュリティ・スクリーニング・プロセスを通過し、許容できない脆弱性を修正し、内部レポジトリ経由に限定して提供されるオープンソース・バージョンに制限することができます。GPLコードに関連するウイルス関係のライセンス問題のため、多くの場合、法務部門はオープンソースの使用制限を追加することを求めてきます。一般に、法務部門がセキュリティ・リスクを理解していると、組織のオープンソース・プラクティスが改善されます。無論、この制御はソフトウェア・ポートフォリオ全体に適用されます。

[SR3.2: 10] ベンダーに標準のことを通知している。

SSGは、組織のセキュリティ標準をベンダーに理解させ、準拠を促進します。契約の文言のみでは、ベンダーとの関係が健全であるとは保証できません。SSGは、ベンダーと協力し、ベンダーのセキュリティ対策について討議し、組織がベンダーに要求する事項を具体的な言葉で説明します(法律用語ではなく)。ベンダーが組織のセキュリティ標準を導入すれば、明らかな成功です。企業のSSDLが公開されている場合は、ソフトウェア・セキュリティに関する要件を簡単に伝達できます。同様に、社内での実施方法や方法を共有すると要件を明確にできます。自社よりセキュリティ・ポリシーが劣るベンダーとの契約は避けてください。

[SR3.3: 10] セキュリティ上安全なコーディング標準を使用している。

セキュリティ上安全なコーディング標準を使用することで、開発者は、明らかなバグを回避し、コード・レビューの基本規則を提供できます。セキュリティ上安全なコーディング標準は、プログラミング言語やプラットフォームごとに必要で、よく使用されるフレームワークやライブラリの使用に言及することもありますが、モバイル・プラットフォームには、独自のコーディング標準が必要です。他の目的で組織にすでにコーディング標準がある場合は、それを基にセキュリティ上安全なコーディング標準を作成できます。セキュリティ上安全なコーディング標準を明確に規定すれば、手動および自動化されたコード・レビューで活用でき、関連のある例を使用することでセキュリティ・トレーニングの内容を強化することもできます。ガイダンスは標準にはならないことに注意してください。