セキュリティ戦略と指標

戦略と指標レベル1

戦略と指標分野では、計画、役割と責任の割り当て、ソフトウェア・セキュリティ目標の特定、予算の決定、指標とゲートの特定を行います。

[SM1.1: 71] プロセス(役割、責任、計画)を公開し、必要に応じて変更している。

ソフトウェア・セキュリティを実行するプロセスでは、すべての関係者が認識できるよう計画を公開します。目標、役割、責任、アクティビティを明示的に定義します。ほとんどの組織が、Microsoft SDLまたはSynopsys Touchpointsなどの公開メソドロジーから選択し、組織のニーズに従ってカスタマイズしています。SSDLプロセスは、組織とセキュリティの両方の状況と共に変化するため、使用している開発プロセス(ウォーターフォール、アジャイル、CI/CD、DevOpsなど)の特性に適応する必要があります。プロセスは公開する必要があります。多くの場合、メソドロジーは、SSGによって管理され、社内のみで公開されます。SSDLは、社外に公開しなくても、必要な影響を与えることができます。

[SM1.2: 66] 広報係を決め、社内マーケティングを行う。

組織ぐるみでソフトウェア・セキュリティを支援するには、SSGのメンバーが広報係を担当する必要があります。この社内広報係は、上級幹部やその他の関係者に、ソフトウェア・セキュリティの問題の規模や、その解決策の要素について最新情報を伝達できます。たとえば、アジャイル・メソドロジーに移行する際に、改善されたソフトウェア・セキュリティ対策を採用するよう、セキュリティに詳しいアジャイル・コーチがチームを先導することができます。広報係は、一般に、上級幹部を含む社内グループとコミュニケーションを取り、外部のスピーカーやホワイトペーパーの作者を社内に招待し、社内Webサイトにホワイトペーパー、書籍、その他のリソースを収集して、その活用を促進します。このような広報係の典型的な例は、マイクロソフトのビル・ゲイツの命令を受けたマイケル・ハワード氏です。

[SM1.3: 67] 上級幹部を教育している。

上級幹部に、ソフトウェア・セキュリティが不十分であったことから起こりうる結果と、セキュリティ対策の不備がもたらすビジネスへの影響を提示します。また、「最近流行の」エンジニアリング手法を何の監視もなく採用するリスクへの対処方法など、他の組織がソフトウェア・セキュリティのために取っている対策も提示します。問題とその適切な解決策の両方を示せば、上級幹部はSSI(ソフトウェア・セキュリティ・イニシアチブ)を、リスク管理上の必須事項として支援する可能性があります。最悪の場合は、これらの事柄を、悪意のあるハッカーによる攻撃や、公共データの漏洩事件発生という最も危険な形態で学習することになります。SSGが、最悪のケースのシナリオを、関連するすべての権限を使って、制御された環境で示すことをお勧めします(たとえば、実際の悪用とそれがビジネスに与える影響)。実行中のSSIのためのリソースを獲得するには、経営陣にプレゼンテーションを行うのが有効な場合もあります。多くの場合、外部の専門家を招くと、上級幹部の注意を引くことができます。モバイルやクラウド・サービスなどの特定の開発分野、または CI/CDやDevOpsなどの特定のメソドロジに絞り込んで話すと、リリース日を早めるといった他の優先事項のために無視されがちなSSGの推奨事項が承認されやすくなります。

[SM1.4: 101] ゲート箇所を特定し、必要な事実関係を収集する。

ソフトウェア・セキュリティ・プロセスには、(多くの場合、複数の)SDLCの中の1つ以上の点のリリース・ゲート、チェックポイント、マイルストーンが含まれます。セキュリティ固有のリリース・ゲートを確立するための最初の2つの手順は、既存の開発方法と互換性のあるゲート箇所を特定し、承認/非承認の意思決定を下すために必要な入力の収集を開始することです。重要なのは、この段階では、ゲートは強制されないことです。たとえば、SSGはリリース前に各プロジェクトのセキュリティ・テストの結果を収集できますが、テストを十分行った、または結果を許容可能とするには何が必要かは判断できません。CI/CDを実施している組織にみられるような短いリリース・サイクルでは、多くの場合、適切な証拠を収集し、軽量で超高速の自動化を使用するなど、画期的な方法が必要です。まずゲートを特定し、後で強制すると、開発でのソフトウェア・セキュリティの促進に非常に効果的です。ゲートの周知を進め、プロジェクトの大部分で次に実行する手順が理解されている状態になってから、ゲートを使用します。このように段階的な方法を取ることで、強制しなくても普及が円滑に進みます。

戦略と指標レベル2

[SM2.1: 47] ソフトウェア・セキュリティに関するデータを社内で公開する。

SSGは、組織内のソフトウェア・セキュリティの状態に関するデータを内部的に公開して、改善を促進します。情報は、指標を表示したダッシュボードを使って上級幹部やソフトウェア開発の管理者に公開できます。会社内のすべての従業員に公開情報が共有されるとは限らず、関係のある上級幹部のみの場合もあります。このような場合、組織内の改革を推進する上級幹部に情報を公開することが必要です。また他の場合では、データをすべての関係者に公開することにより、関係者全員が現状を把握でき、社内の透明化につながります。グループごとの社内競争を啓蒙する組織文化の場合は、この情報により、セキュリティ側面にゲーム性を加えることができます。CI/CDに関連する時間圧縮により、測定をより短時間で正確に行うことが求められ、履歴上の傾向(リリース当たりのバグ数など)より、速度(修正にかかる時間など)が重視されるようになります。

[SM2.2: 42] 測定値にゲートを強制し、例外を追跡している。

SDLCセキュリティ・ゲートは、すべてのソフトウェア・プロジェクトで強制施行されています。ゲートを通過するには、プロジェクトは、規定の測定値に到達しているか、または免除を取得する必要があります。協力的でないプロジェクト・チームでも、これには従う必要があります。SSGが例外を追跡します。ゲートにより、プロジェクトのコード・レビューの実行と、重要な問題を修正してからリリースすることが求められる場合があります。ゲートは、規制や契約上の合意事項、その他のビジネス義務によって求められる制御と直接関連付けられている場合もあり、例外を追跡することが法または規制推進団体によって求められる場合もあります。その他のケースでは、ゲートは、プロセスを統制するために使用される、主要業績評価指標を測定します。入れ替わりが激しい、または形式だけの例外プロセスでは目的を果たせません。自動的に合格となるプロジェクトがあると、ゲートを強制する目的がなくなります。既存のバックエンド用の新しいモバイル・クライアントや、内部データ・センターからクラウド環境へのアプリケーションの接続など、一見無害な開発プロジェクトでも、進行させるには、規定のセキュリティ・ゲートで合格する必要があります。同様に、API、フレームワーク、ライブラリ、COTS、マイクロサービス、コンテナ構成などもすべて、セキュリティ・ゲートを通過する必要があるソフトウェアです。

[SM2.3: 44] サテライトの作成または拡大。

サテライトは、平均以上のレベルのセキュリティに関する関心または技能を持つ、組織全体に分散した従業員の集まりから形成されます 。このグループを特定することが、ソフトウェア開発へのセキュリティの導入を高速化するソーシャル・ネットワークの構築につながります。まず、初期トレーニング・コースの中で目立った人を追跡することをお勧めします( [T3.6 トレーニングを通したサテライトメンバーの特定]を参照)。もう一つの方法は、ボランティアを募ることです。もっとトップダウンなやり方では、初期サテライトメンバーを、すべての開発/製品グループを完全に網羅するよう割り当てます。継続メンバーは、実際の業績を基に決定する必要があります。強力なサテライトメンバーは、成熟したSSIの兆候です。モバイル開発などの急速に変化する技術分野や、開発・運用などの開発パラダイムでは、サテライトメンバーは、ソフトウェア・セキュリティ・スキルと、SSGではあまり取り上げられない分野の知識を組み合わせることができます。特にアジャイル・コーチは、有力なサテライトメンバー候補です。

[SM2.6: 39] セキュリティ・サインオフを要求する。

組織に、セキュリティ・リスクと文書化の説明責任のためのイニシアチブ全体にわたるプロセスが存在します。リスク承認者は、リリース前にすべてのソフトウェアの状態をサインオフします。たとえば、サインオフ・ポリシーでは、低減されていない重要な脆弱性や、省略されたコンプライアンスに関連するSSDL手順に、事業部長がサインオフすることを求めることができます。ポリシーは、小規模なモバイル・アプリケーションなどのアウトソースされたプロジェクトや、クラウドなどの外部環境にデプロイされるプロジェクトにも適用される必要があります。リスクの承認という作業は公式化されている方が効率的(署名済み、書類の提出など)であり、後日参照するために保存できるため、非公式または公式のリスク承認だけでは、セキュリティ・サインオフとはみなされません。同様に、特定のプロジェクトはサインオフする必要がないとするだけでは、必要な結果は達成できません。

戦略と指標レベル3

[SM3.1: 15] ポートフォリオ表示機能を持つ内部トラッキング・アプリケーションを使用している。

SSGは、開発メソドロジーに関係なく、自分の管轄にあるすべてのソフトウェアの進捗をグラフ化する中央集中型のトラッキング・アプリケーションを使用します。このアプリケーションは、計画中、進行中、および完了済みのセキュリティ・アクティビティを記録し、短期間に行われたものも含め、アーキテクチャ分析、コード・レビュー、セキュリティ・テストなどのアクティビティの結果を統合します。SSGは、トラッキング・アプリケーションを使用して、使用する多くの指標のポートフォリオ・レポートを作成します。統合されたインベントリとリスク体勢ビューが必要です。多くの場合、これらのデータは、少なくとも上級幹部の間で公開されます。企業文化によっては、内部競争により有効な効果を上げることができる場合もあります。イニシアチブが成熟し、アクティビティがより広範囲に分散するようになるに従って、SSGは中央集中型のレポート・システムを使用して、すべての活動部分の追跡をします。

[SM3.2: 7] 外部マーケティング・プログラムを実行している。

SSGは、外部から援助を確保するために、企業による、外部へのSSIのマーケティングを支援します。ソフトウェア・セキュリティは、リスク低減運動から、競争上の優位性や市場差別化要因へと成長しています。SSGは、そのSSDLについて論文や書籍を執筆したり、ブログを公開することができます。また、外部のカンファレンスや展示会に参加することもできます。場合によっては、完全なSSDLメソドロジーを公開して外部に宣伝することも可能です。モバイルおよびクラウド・セキュリティ・プロジェクトは、有効なソフトウェア・セキュリティのケース・スタディになります。詳細情報を外部と共有し、評論家を招待すれば企業に新しい視点が生まれる可能性があります。

[SM3.3: 18] 指標を特定し、それを使用して予算を確保する。

SSGとその管理者は、SSIの進捗を定義し測定する指標を選択します。これらの指標を基にイニシアチブの予算が確保され、リソースが割り当てられるため、単純な数値や統計では十分ではありません。また、指標を使用することで、SSGはその目標と進捗を数量的に説明できます。このような指標の例としては、セキュリティ不具合密度が挙げられます。セキュリティ不具合密度の低減は、長期的な修正コストの削減を証明できます。アジャイル・メソドロジーでは、指標は、初期に、多くの場合、軽量な方法で収集されるのが好ましいとされています。ここで鍵となるのは、技術的な結果をビジネス目標と明確でわかりやすい方法で結び付け、予算の正当性を説明することです。セキュリティという概念は、多くのビジネス・パーソンにとってもはや重要事項とは受け取られないため、明示的な関連付けを行うと効果的です。