戦略と指標

戦略と指標レベル1

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

[SM1.1: 81] プロセスを公開し、必要に応じて変更している。

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

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

組織ぐるみでソフトウェア・セキュリティを支援するには、SSGのメンバーが広報係を担当する必要があります。この社内広報係は、上級幹部やその他の関係者に、ソフトウェア・セキュリティの問題の規模や、その解決策の要素について最新情報を伝達できます。たとえば、アジャイル・メソドロジーに移行する際に、改善されたソフトウェア・セキュリティ対策を採用するよう、セキュリティに詳しいアジャイル・コーチがチームを先導することができます。広報係は、理解と信用を高めるために、上級幹部を含む社内グループとコミュニケーションを取り、有名な専門家やホワイトペーパーの作者を社内に招待し、社内Webサイトにホワイトペーパー、書籍、その他のリソースを収集して、その活用を促進します。マイクロソフトのビル・ゲイツが2002年のセキュリティ・メモで新しいセキュリティ戦略を開始した直後にマイケル・ハワード氏が果たした役割は、このような広報係の初期の例です。

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

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

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

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

戦略と指標レベル2

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

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

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

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

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

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

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

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

戦略と指標レベル3

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

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

 

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

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

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

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

[SM3.4: 0] ソフトウェア・デファインド・ライフサイクルのガバナンスを統合する。

組織は、従来のドキュメント、プレゼンテーション、およびスプレッドシートベースのライフサイクル管理をソフトウェアベースのデリバリー・プラットフォームに変更し始めています。ライフサイクルの次フェーズへの進行は、場合によってツールの助けを借り、もはや人が主導しません。代わりに、組織は、SpinnakerなどのALM/ADLMソフトウェアを使用して管理およびデリバリー・プロセスを進めるために自動化に依存し、人はサービスと同様に非同期に(そして多くの場合は随時に)参加します。自動化は、多くの場合、CI/CDの範囲を超えて、ヘルスチェック、障害時のカットオーバー、既知の正常なソフトウェアへのロールバック、不具合の発見と管理、コンプライアンス検証、ポリシーと標準の遵守を確保する手段といった、デリバリーの機能的および非機能的側面を含みます。一部の組織では、コンプライアンスと不具合検出データを統合して、一連の特定時点での承認/非承認の意思決定(各ゲートでのセキュリティ・テストなど)から保証データの継続的な蓄積(開発および運用環境に組み込まれたセンサーからの出力など)の将来の状態に移行することにより、ライフサイクル管理アプローチを進化させています。