標準と要件

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

標準と要件レベル1

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

SSGは、ポリシーに適合し、特定のセキュリティ中心の運用を行うための承認された方法を説明する標準を作成することによって、組織のセキュリティ・ガイダンス需要に適合します。標準では、たとえば、Androidデバイス上の認証の実行方法や、ソフトウェア・アップデートの信頼性を判断する方法について説明し、SSGが参照実装を提供します。多くの場合、アプリケーション以外のソフトウェア(APIやマイクロサービス・アーキテクチャなど)に独自の標準は必要ありません。標準はさまざまな方法で展開し、実用性と妥当性を維持することができます。標準は開発環境で自動化したり(IDEやツールチェーンに作り込むなど)、コード例やコンテナに明示的に結び付けることが可能です。いずれにせよ、標準とみなされるためには、採用して施行する必要があります。

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

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

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

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

標準と要件レベル2

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

組織は、標準の規定に使用されるプロセスを公式化するための審査委員会を設立し、すべての関係者の意見が反映される機会を作ります。審査委員会を運営する場合には、提案された標準の支持者を任命します。支持者には、標準が目標を満たしていることを証明し、審査委員会から承認を得て委任される義務があります。企業のアーキテクチャまたは企業のリスク・グループに、標準審査委員会の設立や管理責任を委任できる場合もあります。標準を直接ソフトウェアとして実装する場合、DevOpsマネージャー、リリース・エンジニア、あるいは関連するコンテナまたはサービス・レジストリの所有者が推進リーダーの役割を果たす可能性があります。

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

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

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

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

標準と要件レベル3

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

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

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

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

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

セキュリティ上安全なコーディング標準を使用することで、組織の開発者は、明らかなバグを回避し、コード・レビューの基本規則を提供できます。これらの標準は、プログラミング言語やプラットフォームごとに必要で、よく使用されるフレームワークやライブラリの使用について規定することもあります。プラットフォームとしては、モバイルまたはIoTランタイム、クラウド・サービス・プロバイダーAPI、SaaSプラットフォーム(Salesforce、SAPなど)が考えられます。他の目的で組織にすでにコーディング標準がある場合は、それを基にセキュリティ上安全なコーディング標準を作成できます。セキュリティ上安全なコーディング標準を明確に規定すれば、手動および自動化されたコード・レビューで活用でき、セキュリティ・トレーニングのための適切な例を提供することもできます。セキュリティ上安全なコーディング標準を自動化に直接統合することを選択するグループもありますが、標準に対する違反も修正すべき欠陥と見なす必要があります。セキュリティ上安全なコーディング標準が具体的でなく、施行されていなければ効果がないということを銘記してください。

[SR3.4: 24] テクノロジー・スタックの標準を規定する。

組織は特定のテクノロジー・スタックを標準化します。グループは、新しいプロジェクトごとに新しいテクノロジー・リスクを調査しなくてもすむため、SSGの仕事量が軽減されます。スタックを安全に使用するために必要な仕事量が減るため、組織が、テクノロジー・スタックごとにセキュリティ上安全な基本構成を構築することが理想的です。スタックには、オペレーティング・システム、データベース、アプリケーション・サーバー、ランタイム環境(LAMPスタックなど)が含まれます。アプリケーション・サーバーと開発フレームワークのバンドル(MEANなど)、あるいはクラウド環境のレイヤ1~6(FaaS:Function as a Service)がスタックになる場合もあります。スタックは、セキュリティの最先端領域に集まっています。モバイル・テクノロジー・スタックおよびプラットフォーム、IoTデバイス、クラウドベースのテクノロジー・スタックが、セキュリティに関する情報が集まっている分野です。コンテナ・ベースの手法を用いることにより、標準化の拡張性を高めることができます([SE3.4 アプリケーション・コンテナを使用している]を参照)。