BSIMM: ソフトウェア・セキュリティ対策向上への5つの重要なステップ

SSIの目標は、全工程でのセキュリティの向上です。BSIMM11で観察されたこれらの重要なステップに従って、SSIの開始または向上に取り組みましょう。

ソフトウェア・セキュリティに関心があるなら（今日ビジネスを行うということは、事業内容や何を生産しているかに関わらず、ソフトウェア会社でもあることを意味するので、関心を持つべきですが）、Building Security In Maturity Model（BSIMM）にも関心があるはずです。BSIMMはセキュリティを強化するためのロードマップとしての役割を果たします。

年次レポートとして現在11回目の版を重ねているBSIMMの焦点は、ソフトウェア・セキュリティ・イニシアティブ(SSI)です。これは、組織とそのスタッフ、プロセス、ソフトウェア・ポートフォリオの個別ニーズに合わせて構成された標準、ポリシー、指標を組み合わせたものです。SSIの目標は、設計、構築、保守を含む、ソフトウェアの全工程のセキュリティを向上させることです。

BSIMMの進化

2008年以来、BSIMMチームは複数の業界の211の組織のSSIを追跡してきました。今年のレポートは、主に9つの業界と複数の地域にわたる130の参加企業の詳細な観察に基づいています。

レポート全文をダウンロードできます。このレポートはクリエイティブ・コモンズ表示-継承3.0のライセンスに基づき、常時無料で公開されています。

この投稿では、SSIの立ち上げ・向上に取り組む組織に向けてBSIMM11が示している指針に焦点を当てます。

BSIMMは、実践のための定型的な方法を述べたものではなく、組織が実際に多くの時間と費用を費やしているソフトウェア・セキュリティ・アクティビティを観察し、報告するものです。このレポートは取扱説明書ではなく、測定軸およびロードマップとみなされていますが、その観察結果は、組織がSSIの立ち上げ・向上を図る上で役立つ5つのステップを概説しています。

1. SSIフェーズの特定

業種や個別のプラクティスを問わず、SSIを実装する組織は通常3つのフェーズに従って進展していきます。

導入期

これには、SSIを新規に立ち上げるか、場当たり的に行われていたセキュリティ・アクティビティを形式化しようとしている組織が該当します。このフェーズには、最初の戦略の定義、基盤的なアクティビティの実装、おおまかなロードマップの作成が含まれます。このフェーズでは、一般的に予算、リソース、人材の不足が障害になります。この段階を乗り切るには平均12～24か月かかります。

熟成期

これには、SSIをすでに持っているか、または導入しつつあり、経営陣の期待事項のスケーリング、合理化、実現に取り組んでいる組織が該当します。このフェーズでは、既存のアクティビティを企業のテクノロジー・スタック、部門、ソフトウェア・ポートフォリオのより多くの部分に適用しようと努めます。また、SSIの責任者は、アクティビティの数を減らし、すでに実施中のアクティビティの深さ、広がり、費用対効果の改善に努める場合があります。

最適化期

これには、既存のSSIを微調整できるレベルの組織が該当します。このフェーズでは、SSIの管理者が運用上の期待および関連する指標を明確に可視化しており、テクノロジーの変化を促す要因にシームレスに適応し、差別化要因としてリスク管理とビジネスの価値を明確に実証します。また、SSIのリーダーは、テクノロジー幹部からビジネス側へと変わっていくこともあります。

組織によって違いがあるため、すべての組織のSSIが導入期から最適化期に向かって一方向にまっすぐ進むわけではありません。SSIの進展においては、特定のプラクティスやアクティビティが特に遅れたり、大きく先行したりする場合があります。組織によっては、特定のサイクルを何度か繰り返してから次のフェーズに進むこともあります。各SSIとその人員、プラクティス、ツール、スキルセットの複雑さと差異を考えると、これらのフェーズは進展の大まかな指標に過ぎません。ロードマップはすべての組織が一様に同じ道をたどることを強制するものではありません。

各組織は、各フェーズで見つかった共通の指標を確認し、現在のSSI成熟度を反映したフェーズがどれかを独自に評価する必要があります。これにより、SSIの成熟フェーズに最適なBSIMM11のアクティビティを判断しやすくなります。

2. DevOpsアクティビティの採用と実装

過去10年間で、BSIMMは、SSIの管理と開発には2つの文化があり、企業は通常そのいずれかを選択することを発見しました。すなわち、中央の本社機能の下で形成・管理される場合とエンジニアリング部門のリーダーシップの下で管理される場合です。最初のモデルは、主にコンプライアンス、リスク管理、テストに焦点を当てています。2つ目のモデルは、セキュリティ標準、開発プロセス、チーム間の連携に重点を置いています。

どちらの場合も、SSIは同じ中央集権型の専門のソフトウェア・セキュリティ・グループ（SSG）によって運営されます。BSIMMが重視しているのは、SSIに最適な文化は何かではありません。SSGが率先して機敏に部門間のギャップを埋め、異なるチーム間のアクティビティを標準化することの必要性に重点を置いています。

エンジニアリング主導のソフトウェア・セキュリティの取り組み

実際、DevOpsに移行した開発環境では、プラクティス、ツール、アクティビティのすべてが高速かつ高品質なデリバリーに重点を置いており、以前は個別に機能していたチーム間の協力と連携の必要性がさらに重要になります。

BSIMM11では、エンジニアリング・チームが自らソフトウェア・セキュリティの取り組みを立ち上げているのは、次の2つの要因からであることがわかりました。

• 企業プロセスの分裂、納期の混乱、部門間の人間関係の問題、人手を要するプロセスの増加などの形で生じる摩擦。これらのすべてが開発を遅らせる要因になります。
• アジャイルとDevOpsのデリバリー・プラクティスには、エンジニアリングレベルでの関与が必要です。また、DevOpsのセキュリティには企業のツールやプロセスだけではカバーしきれない要素があります。

BSIMM11では、DevSecOpsへの移行についても言及しています。DevSecOpsとは、DevOps開発ライフサイクルのあらゆる側面にセキュリティを「組み込む」ことにより開発の支援、速度の向上、摩擦の低減、連携の強化を図るものです。

これらの調査結果は、エンジニアリングのセルフサービス、開発ライフサイクルにおける自動化、摩擦要因の除去を考慮したSSIの必要性を示しています。

SSIの開発にはDevOpsの文化が不可欠

独自のSSI戦略およびプラクティスを策定する際には、DevOpsの文化をアクティビティと考慮事項に含める必要があります。自動化（特にソフトウェア定義のセンサーとチェックポイント）により、一貫性を実現し、プロセスを遅滞させる原因となる不要な人手の介在を回避することができます。

しかし、スピードの必要性を重視するあまりセキュリティに対する十分な配慮を怠ることのないようにしなければなりません。DevOpsのスピードについていくことができるセキュリティのプラクティスとツールが不可欠です。

3. 新しいSSIに関して検討を要する主要アクティビティ

アクティビティはBSIMMの中心となるものであり、業界内でのアクティビティの普及や消滅は全体的な傾向、成功したアクティビティ、失敗したアクティビティを示しています。アクティビティとは、個別のプラクティスの一環として、ソフトウェア・セキュリティ・グループ（SSG）によって実行または推進されるセキュリティ対策のことです。

今年の報告書では、BSIMMに最近追加されたいくつかのアクティビティの飛躍的な増加が見られました。この事実は、これらのアクティビティの広範囲な有用性と、さらには現在のSSIにおける効果や不可欠な役割を示すものです。以下に示すアクティビティと簡単な説明を検討して、自社のSSIに適用できるかどうか、適用できるとすれば、改善または実装が可能かどうかを判断してください。

• SE（ソフトウェア実行環境）3.5 コンテナおよび仮想化環境にオーケストレーションを使用する

自動化を使用して、サービス、コンテナ、および仮想環境を統制のとれた方法で拡張します。オーケストレーション・プロセスでは、アドオンのセキュリティ機能（逸脱に対するハードニング、秘密管理、ロールバックなど）を利用し、デプロイ済みの各ワークロードが事前に決定したセキュリティ要件を満たすようにします。

• SE2.6 クラウド・セキュリティの基礎を徹底する

ホストとネットワークの基本的なセキュリティが導入済みであることを確認した上で、クラウド環境でも基本要件が満たされていることを確認する必要があります。BSIMM11の記載にあるとおり、「ユーザー企業が使用するセキュリティ・ソフトウェアを提供する責任は100%クラウド・プロバイダーにありますが、ソフトウェア・セキュリティに対する責任は100%ユーザー企業にあります。」

• SE3.6 運用BoM（Bill of Materials）を使用してアプリケーション・インベントリを強化する。

所有していることに気付いていないものを守ることはできません。したがって、健全な企業にとって、本番環境におけるアプリケーションとその保存場所の一覧は不可欠です。また、すべての本番ソフトウェアに関して、コンポーネント、依存関係、構成、外部サービスなどを詳細に記載したマニフェストがあれば、組織のセキュリティ強化に有益です。また、攻撃者や攻撃が進化し、コンプライアンス要件が変化し、パッチの適用対象となる項目数が増えた場合に機敏に対応する上でも役立ちます。

• CMVM（構成管理と脆弱性管理）3.5 運用インフラストラクチャのセキュリティ検証を自動化する

SSGがエンジニアリング・チームと共同で管理されたセルフ・サービス・プロセスを促進し、これによって従来のIT業務（アプリケーションやインフラストラクチャのデプロイなど）を置き換え、セキュリティ・プロパティ（合意されたセキュリティ・ハーデニングへの遵守など）の検証もこのプロセスで実行するようにします。最近ではエンジニアがネットワーク、コンテナ、マシン・インスタンスっを作成して、デプロイメントのオーケストレーションを実行し、これまでITが全面的に責任を負っていたその他のタスクも実行するようになっています。

4. 上記の重要なアクティビティがSSIに含まれていることを確認する

組織のSSIのフェーズを問わず、BSIMM11の調査結果は12のプラクティスのそれぞれについて、最も一般的なアクティビティを文書化しています。これらのアクティビティはすべてのSSIに必須だというわけではありません。しかし、大きな成功を収めたイニシアティブの大半に見られることから、その重要性がうかがわれます。

5. SSIを活性化するために手順を実装する

前述のように、SSIには企業主導とエンジニアリング主導の2つの経路または文化があります。BSIMMは、各経路について「始める手順」の推奨事項を用意しています。BSIMMレポートを入手したら(無料です)、まず、どちらが自社のSSIに合うか判断し、該当するチェックリストを確認してください。