Sorry, not available in this language yet
よくあるご質問
ここには、BSIMMに関してよくあるご質問が記載されています。完全版をお読みになるには、こちらからBSIMMレポートをダウンロードしてください。
BSIMMとは
BSIMM（「ビー・シム」と発音します）は、Building Security In Maturity Modelの略で、日本語では「セキュア開発成熟度モデル」と呼ばれています。BSIMMレポートは、ソフトウェア・セキュリティ・イニシアチブ（SSI）の進捗状況を確認し、長期的な実行計画を立てるために構成された、実践的なソフトウェア・セキュリティ対策の調査です。
ソフトウェア・セキュリティが必要な理由はなんですか？
ソフトウェア・セキュリティとは、攻撃されてもセキュリティ上安全なソフトウェアを構築することです。長年にわたるネットワーク・セキュリティ侵害のレビューからわかったことは、セキュリティを当初から組み込んでソフトウェアを開発することで、ソフトウェアの保護がより容易となるということです。また、セキュリティはモノではなく（モノの）特性であるため、暗号やパスワードなどのセキュリティ機能をソフトウェアに追加するだけでは攻撃に対する耐性を得るソフトウェア・セキュリティは実現できません。
ソフトウェア・セキュリティを考慮する必要があるのはどんな人ですか？
業務でソフトウェアを開発および使用する組織（現代社会ではすべての組織）には、大量のIDデータの漏洩や、多額の賠償責任、悪意のあるユーザーによる機密情報の入手を許さないソフトウェアが必要です。ソフトウェアの信頼性を高める唯一の方法は、セキュリティを組み込んで開発することです。つまり、ソフトウェアを使用するすべての組織にBSIMMが必要なのです。
BSIMMの特長はなんですか？
弊社は、すべて、実際のソフトウェア・セキュリティ対策を調査し観察した結果からBSIMMを開発しました。BSIMMによって、何をするべきかはわかりませんが、他社が実際に何をしているかがわかります。ソフトウェア・セキュリティ・サイエンスに対するこの「観察と報告」によるアプローチは、個人的な経験に基づいた規範的アプローチと大きく異なります。
どんな組織が調査対象に含まれていますか？
130の企業がBSIMM13の対象に含まれています。これらの企業は、現在の評価の時点で、平均で5年間にわたってソフトウェア・セキュリティ対策を実施してきました。130社すべてが、ソフトウェア・セキュリティ専任の内部グループを任命してソフトウェア・セキュリティ・グループ（SSG）イニチアティブを成功させることに合意しました。SSGの規模は平均で25.7名（最小1名、最大892名、中央値8.0名）です。通常、他のサテライト・グループ（開発者、アーキテクト、およびソフトウェア・セキュリティに直接従事し推進している組織の従業員）は平均112名（中央値40名）で構成されます。参加組織の開発者の平均人数は2,146名（最小25名、最大100,000名、中央値800名）で、開発部門のSSGメンバーの平均割合は5.11%です。
全体では、BSIMMレポートでは、11,850名のSSGメンバーが、約410,000名の開発者が約145,000のアプリケーションで優れたセキュリティ業務を遂行できるよう支援していることが報告されています。
誰がソフトウェア・セキュリティの責任を追うべきですか？
今回調査されたソフトウェア・セキュリティ対策を管轄する幹部の役職は、以下に例を示します。
- コーポレート・セキュリティ担当アシスタント・バイス・プレジデント
- アプリケーション・セキュリティ担当部長
- セキュリティ保証担当部長
- 情報セキュリティ担当バイス・プレジデント
- アプリケーション・リスク管理担当バイス・プレジデント
- シェアード・サービス担当上級部長
- ソフトウェア・セキュリティ・エンジニアリング担当マネージャー
- エンタープライズ・ソフトウェア担当上級部長
- インフラストラクチャ/セキュリティ担当上級部長
- グローバル情報セキュリティ・イノベーション担当上級部長
- セキュリティ・テスト担当グローバル責任者
- システム開発担当システム・マネージャー
- セキュリティ・アーキテクト
- 製造オペレーション担当執行役員
- 情報セキュリティ・オペレーション担当マネージャー
- 情報システム担当マネージャー
- 組み込みシステム/サイバーセキュリティ担当リーダー
組織のどこにSSGが配置されているかについて広範囲にわたって調査しました。BSIMM-Vでは、67社中21社でCISOを直近の経営幹部と見なしていました。それが、BSIMM6では78社中31社に、BSIMM7では95社中52社に増加しました。それ以降は、BSIMMのコミュニティが大きくなっても、その割合は比較的横ばいになっています。図1は、ソフトウェア・セキュリティ対策を監督しているさまざまな経営幹部を示しています。
図1：SSGの直近の経営幹部
BSIMMには何が含まれますか？
BSIMMを構成する主な機能はソフトウェア・セキュリティ・フレームワークです。このフレームワークはガバナンス、インテリジェンス、SSDLタッチポイント、デプロイメントの4つの領域で構成され、それぞれに12のプラクティスがあります。
- ガバナンス：戦略と指標、コンプライアンスとポリシー、トレーニング
- インテリジェンス：攻撃モデル、セキュリティ機能と設計、標準と要件
- SSDLタッチポイント：アーキテクチャ分析、コード・レビュー、セキュリティ・テスト
- デプロイメント：ペネトレーション・テスト、ソフトウェア環境、構成管理と脆弱性管理
BSIMM13では、プラクティスごとに関連するアクティビティが用意され、合計125のアクティビティがあります。調査では、各アクティビティが何回観測されたかを追跡しました。（各アクティビティを解釈するには、125のアクティビティについて詳細に説明しているBSIMMレポートをダウンロードしてください）。
アクティビティごとに説明と、組織での実施方法を示すための実例が示されています。これらの例は特定のアクティビティを実行する唯一の方法ではなく、実際のソフトウェア・セキュリティの取り組みを理解する助けになるよう挙げられています。
図2：BSIMM13企業スコアカードの例
セキュリティ・アクティビティ数が125と多いのはなぜですか？
心配には及びません。BSIMMは観測によるモデルであり、複数の参加組織で行われているアクティビティが観測されるたびにモデルに追加されます。モデルはあくまで累積であり、すべてのアクティビティを実行している組織はありません。長年にわたり、金融サービス組織、独立系ソフトウェア・ベンダー（ISV）およびIoT企業の多数の共通部門を調査してきましたが、その中のイニシアチブは同一とは程遠く、まったく同じ方法で行っている企業はありませんでした。たとえば、他人の家計計画をそのまま使用することはないでしょう。ソフトウェア・セキュリティ・イニシアチブも同様です。BSIMMは、そのままに従うレシピではなく、アイディアを示す一般的なガイダンスとして参照されるべきです。
BSIMMスコアカードで強調表示されているアクティビティがあるのはなぜですか？
図3に表示されている12のアクティビティは、各プラクティスで最も多く観測された（実施されていた）アクティビティです。
図3：プラクティス別の最も一般的なアクティビティ
視覚的な資料があるとわかりやすいです。これをグラフ表示するとどうなりますか？
12のプラクティスについて多数の企業の平均成熟レベルを示した3つのレーダー・チャートは、BSIMMが提供する分析能力の例を示しています。図4は、すべてのBSIMM企業（参加企業全体）のデータを示します。図5は、非テクノロジ企業と比較してプロットされたテクノロジ企業のデータを示します。
図4：参加企業全体のデータ
図5：テクノロジ企業と非テクノロジ企業の比較
BSIMMの3つの業種、金融サービス、医療、保険は、規制が厳しい業界に属しています。BSIMMでの長い経験上、大手金融サービス会社は、保険会社や医療業界の会社よりも早くSSIを開始することで規制圧力に対応してきたことがわかっています。しかし、金融サービスと保険業界の企業のSSG平均年数は、今回初めて同じ5.2年になりました。これに対し、医療業界の企業は4.5年です。この年数の差は縮まっているものの、金融サービス業界の企業は、依然として高い成熟度を示しています。これは、金融サービス業界におけるソフトウェア・セキュリティ・アクティビティの長い歴史とともに、比較的新しいが成熟したSSGを持つ若い金融サービス企業の流入を反映していると考えられます。
医療業界の組織には、成熟度の外れ値がいくつか含まれていますが、図6に示すように、これら 3 つの規制産業のデータを比べると、ほとんどのプラクティスで他の業界に遅れをとっているものの、アーキテクチャ分析では先行しています。
金融サービス業界の企業と比較すると、保険業界はセキュリティ・テストで進んでいますが、他のプラクティスでは僅差か、遅れています。保険業界と金融サービス業界の間で最も大きな差があるのは、コンプライアンスとポリシー、セキュリティ機能と設計、侵入テスト、構成管理と脆弱性管理であり、金融サービス業界が保険業界をリードしています。
図6：規制の厳しい業界
調査対象のすべての組織はソフトウェア・セキュリティの知識を持っていますか？
いいえ。この調査では、各企業のスコアを計算することで、ある企業と他の企業と比較した相対成熟度と平均成熟度を見ることもできます。BSIMM13では、BSIMMスコアの範囲は41～50です。それに対し、BSIMM12では31～40です。
図7で明らかなように、一般に企業が成熟し、BSIMMを評価ツールとして長期にわたって継続的に使用すると（ラウンド2、ラウンド3+のように）、スコアが高くなる傾向があります。
図7：BSIMM13のスコア分布
BSIMMは規格ですか？
BSIMMは、ISO 27001や卓球の公式ルールのような規格ではありません。BSIMMは、規格ではなく、世界で最も成功しているソフトウェア・セキュリティ対策によって実践されているアクティビティを示します。この意味で、BSIMMは、組織が実際に実践している事実上の標準といえます。頭の中で考えられた理念ではなく、現場で実際に行われている実践方法といえます。
BSIMMの使用方法は？
あなたの組織でソフトウェア・セキュリティ対策がまだ実践されていないとすれば、実践する必要があります。BSIMMはその足がかりになります。ソフトウェア・セキュリティ・グループに何名の従業員が必要か、まず着手すべきことは何か、そして今後数年で行うべきことを特定できます。ソフトウェア・セキュリティ対策がすでに開始されている場合は、BSIMMを使用して、その進捗状況を把握し、今後の計画を策定することができます。
BSIMMの利用料金は？
BSIMMは無料で利用できます。BSIMMは、Creative Commonsライセンスでリリースされています。つまり、他のモデルと同様に「オープン」なものであり、社内文書のたたき台として使用したり、我々の公開データを基に独自のモデルを作ったりすることができます。ただし、その場合、その資料の参照元を公表することが義務づけられています。つまり、BSIMMを参照したことを明記してください。ご不明な点がございましたら、お問い合わせください。
ソフトウェア・セキュリティ・グループとは何ですか？ これは必須ですか？
すべてのBSIMM参加企業には、SSGと呼ばれる、ソフトウェア・セキュリティ専任の社内グループが存在します。SSGなしにBSIMMアクティビティを成功裏に実践している組織は見たことがありません。調査対象の130の組織全体で見ると、開発部門の平均3.01%がSSGメンバーです。開発者の人数が800名以下の組織の場合、最大割合は51.4%で、最小は5.11%でした。開発者の人数が800名を超える組織の場合、最大割合は14.9%で、最小は1.03%でした。実際の数値では、130の企業のSSGの平均規模は25.7名（最小1名、最大892名、中央値8名）です。
BSIMMがそれほど重要なら、今までなかった理由は何ですか？
ISV、銀行、医療業界の企業、官公庁などの多くのソフトウェア開発組織にとって、ソフトウェア・セキュリティが問題となってきたのは21世紀に入ってからで、上級幹部レベルで真剣に問題視されるようになったのはここ10年以内のことです。「私たち」は、組織として、マクロ・レベルで何が有効か、お互いの経験を突き合わせて蓄積する水準にやっと到達しました。セキュア・プログラミング、ペネトレーション・テストなどが話題になっていますが、ソフトウェア・セキュリティ対策を形成する最適な方法を特定するにはさらに時間がかかります。BSIMMは、誰でも無料で利用できるオープンな観察型のモデルに対象アクティビティを取り込んでいます。
私は理解しましたが、私の上司は理解していません。ソフトウェア・セキュリティ対策はどのように始まったのですか？
長年のBSIMMで、ITセキュリティが主流となる時代にあったような、ソフトウェア・セキュリティを正当化する必要性を感じています。当時は、ファイアウォールが必要な理由や侵入検知機能によって小さな問題が大きな問題に拡大するのを防止できること、あるいはセキュリティについての従業員の意識を変えることで企業文化が変わることを理解していない経営幹部が存在しました。この時代では、頭では問題を理解している幹部でも、実際に企業で被害が出るまで、導入をためらうという現象が見られました。
BSIMMデータ・プールでは、ソフトウェア・セキュリティ・グループが以下のようなさまざまな状況で予算を獲得していることがわかっています。
- 上級幹部がセキュアなソフトウェアを開発することを宣言して、そのために必要な予算を確保した（セキュリティを最重要課題にするよう指示したマイクロソフトのビル・ゲイツによる2002年のセキュリティ・メモの例）。
- なんらかの形のコンプライアンスを担当している上級幹部グループが、（おそらくは大きな犠牲を伴う失敗を経て）企業のガバナンス・プロセスとしてソフトウェア・セキュリティを必要な経費とみなした。
- ITセキュリティ担当者が、データ漏洩の責任はITセキュリティ部門の責任ではなく、企業のアプリケーションの脆弱性にあることを証明した。
- 影響力のあるソフトウェア・セキュリティ起業家（CIO、CTO、法的またはガバナンス団体）が先導してシステムを構築し、初期の成功を基に実際のプログラムの予算を獲得した。
- 開発グループは、DevOpsへの移行の一環としてさまざまな「セキュリティ」の役割（クラウド・セキュリティ、ビルド・セキュリティ、コンテナ・セキュリティなど）を有機的に発展させ、上級幹部がその取り組みを標準化して、すべての開発グループに知識とプロセスを教え込むプログラムに取り入れました。
今日の問題において困難な点は、上級幹部に問題の重要性を訴えることでは必ずしもなく、自分がその問題解決の責任者として適任であり、かつ具体的な計画を持っていることを納得してもらうことにあるようです。ソフトウェア・セキュリティの責任者は、重大なソフトウェア・セキュリティの問題が発生した場合には解雇される可能性があります。しかし将来の問題解決のためのリソースが現在得られないのであれば、今すぐに退社したほうがよいでしょう。セキュリティの問題に対応しないような組織に未来はありません。自分の能力を活用できる場は他にもたくさんあります。
最新のBSIMM調査で重点が置かれている主なテーマをいくつか教えてください。
シフト・エブリウェア
企業は15年以上前から、「シフト・レフト」のトレンドを受けて、セキュリティ・テストを開発プロセスの早期段階に移行することに重点を置いてきました。現在は、このトレンドが拡大して、SDLCを通じて継続的にセキュリティ・テストを行う「シフト・エブリウェア」に移行しています。「シフト・エブリウェア」のアプローチは、脆弱性をタイムリーにテストすることだけに有効なのではありません。SDLCのすべてのフェーズにおいて、ガバナンスチェックの自動化やリスク測定を容易にもします。
ソフトウェア・サプライ・チェーンのリスク管理
サプライ・チェーンの不安定さやサードパーティ製ライブラリで見つかった重大な脆弱性にメディアの関心が高まり、経営幹部は、企業固有のSDLCに起因するものではないセキュリティ・リスクにますます注目しています。ソフトウェア・サプライ・チェーンのリスクを管理する取り組みとして、自社開発のソフトウェアに統合されたソフトウェアの追跡と保護、およびソフトウェア・サプライヤがベスト・プラクティスに従うようにすることに重点を置いています。
開発チームのツールチェーンへのセキュリティ統合
開発チームとソフトウェア・ベンダーは、CI/CDパイプラインとツールチェーンにセキュリティ・オプションを統合することで前進し続けています。これらの統合により、摩擦を減らし、カバレッジを向上させ、「シフト・エブリウェア」の概念を現実のものとする、迅速で厳密なプロセスが実現します。
アプリケーションと製品を超えたソフトウェア・セキュリティの拡大
アプリケーション・セキュリティ・チームは、Infrastructure-as-Code（IaC）、コンテナ、クラウド・プラットフォームなど、ソフトウェア・セキュリティが拡大されるたびに追随する必要がありました。新たなセキュリティ領域に対応するための鍵は、企業内でのSSIの位置付けを再定義することです。セキュリティに対して人任せのテストと適用を繰り返すアプローチでは、もはや十分ではありません。したがって、SSIのリーダーは、そのインフラストラクチャが安全に構築されるように、その社員にとってのソート・リーダー、インフルエンサー、メンター、そしてイネーブラーとなる必要があります。
