よくあるご質問
ここには、BSIMMに関してよくあるご質問が記載されています。完全版をお読みになるには、こちらからBSIMMレポートをダウンロードしてください。
BSIMMとは
BSIMM（「ビー・シム」と発音します）は、Building Security In Maturity Modelの略です。BSIMMは、ソフトウェア・セキュリティ・イニシアチブの進捗状況を確認し、長期的な実行計画を立てるために構成された、実践的なソフトウェア・セキュリティ対策の調査です。
ソフトウェア・セキュリティが必要な理由はなんですか？
ソフトウェア・セキュリティとは、攻撃されてもセキュリティ上安全なソフトウェアを構築することです。長年にわたるネットワーク・セキュリティ侵害のレビューからわかったことは、セキュリティを当初から組み込んでソフトウェアを開発することで、ソフトウェアの保護がより容易となるということです。また、セキュリティはモノではなく（モノの）特性であるため、暗号やパスワードなどのセキュリティ機能をソフトウェアに追加するだけでは攻撃に対する耐性を得るソフトウェア・セキュリティは実現できません。
ソフトウェア・セキュリティを考慮する必要があるのはどんな人ですか？
業務でソフトウェアを開発および使用する組織（現代社会ではすべての組織）には、大量のIDデータの漏洩や、多額の賠償責任、悪意のあるユーザーによる機密情報の入手を許さないソフトウェアが必要です。ソフトウェアの信頼性を高める唯一の方法は、セキュリティを組み込んで開発することです。つまり、ソフトウェアを使用するすべての組織にBSIMMが必要なのです。
BSIMMの特長はなんですか？
弊社は、すべて、実際のソフトウェア・セキュリティ対策を調査し観察した結果からBSIMMを開発しました。BSIMMによって、何をするべきかはわかりませんが、他社が何をしているかがわかります。ソフトウェア・セキュリティ・サイエンスに対するこの「観察と報告」によるアプローチは、個人的な経験に基づいた規範的アプローチと大きく異なります。
どんな組織が調査対象に含まれていますか？
128の企業がBSIMM12の対象に含まれています。最新の評価では、平均で4.4年間にわたってソフトウェア・セキュリティを実施しました（2021年9月の時点で、1年未満～16年間）。128社すべてが、ソフトウェア・セキュリティ専任の内部グループを任命してソフトウェア・セキュリティ・グループ（SSG）イニチアティブを成功させることに合意しました。SSGの人数は平均で22.2名（最小1名、最大892名、中央値7.0名）です。通常、他のサテライト・グループ（開発者、アーキテクト、およびソフトウェア・セキュリティに直接従事し促進に努めている組織の従業員）は平均で50.4名（最小0名、最大1,500名、中央値1名）で構成されます。参加組織の開発者の平均人数は3,113.6名（最小5名、最大10万名、中央値850名）で、開発部門のSSGメンバーの平均割合は2.59%（中央値0.74%）です。
全体では、BSIMMは、9,285名のSSGメンバーと、398,544名の開発者が開発したソフトウェア（約15万3,519のアプリケーション）をセキュリティ保護するサテライト・メンバーで構成されます。
誰がソフトウェア・セキュリティの責任を追うべきですか？
今回調査されたソフトウェア・セキュリティ対策を管轄する幹部の役職は、以下に例を示します。
- コーポレート・セキュリティ担当アシスタント・バイス・プレジデント
- アプリケーション・セキュリティ担当部長
- セキュリティ保証担当部長
- 情報セキュリティ担当バイス・プレジデント
- アプリケーション・リスク管理担当バイス・プレジデント
- シェアード・サービス担当上級部長
- ソフトウェア・セキュリティ・エンジニアリング担当マネージャー
- エンタープライズ・ソフトウェア担当上級部長
- インフラストラクチャ/セキュリティ担当上級部長
- グローバル情報セキュリティ・イノベーション担当上級部長
- セキュリティ・テスト担当グローバル責任者
- システム開発担当システム・マネージャー
- セキュリティ・アーキテクト
- 製造オペレーション担当執行役員
- 情報セキュリティ・オペレーション担当マネージャー
- 情報システム担当マネージャー
- 組み込みシステム/サイバーセキュリティ担当リーダー
組織のどこにSSGが配置されているかについて広範囲にわたって調査しました。特に、参加企業128社中67社のSSGがCISOによって、またはCISOを直近の上級経営幹部とする人物によって運営されています。18社がCTOを直近の上級経営幹部とし、4社がCIO、11社がCSO、3社がCOO、2社がCRO、1社がCAOの下にSSGを配属しています。19社のSSGは技術または製造部門の組織に所属しています。
BSIMMには何が含まれますか？
BSIMMを構成する主な機能はソフトウェア・セキュリティ・フレームワークです。このフレームワークはガバナンス、インテリジェンス、SSDLタッチポイント、導入の4つの領域で構成され、それぞれに12のプラクティスがあります。
- ガバナンス：戦略と指標、コンプライアンスとポリシー、トレーニング
- インテリジェンス：攻撃モデル、セキュリティ機能と設計、標準と要件
- SSDLタッチポイント：アーキテクチャ解析、コード・レビュー、セキュリティ・テスト
- 導入：ペネトレーション・テスト、ソフトウェア環境、構成管理と脆弱性管理
BSIMM12では、プラクティスごとに関連するアクティビティが用意され、合計122のアクティビティがあります。調査では、各アクティビティが何回観測されたかを追跡しました。以下が調査で得られたデータです （各アクティビティを解釈するには、122のアクティビティについて詳細に説明しているBSIMMレポートをダウンロードしてください）。
アクティビティごとに説明と、組織での実施方法を示すための実例が示されています。例は特定のアクティビティを実行する唯一の方法ではなく、ソフトウェア・セキュリティの現実を示す意図で挙げられています。
セキュリティ・アクティビティ数が122と多いのはなぜですか？
心配には及びません。BSIMMは観測によるモデルであり、複数の参加組織で行われているアクティビティが観測されるたびにモデルに追加されます。モデルはあくまで累積であり、すべてのアクティビティを実行している組織はありません。長年にわたり、金融サービス組織、独立系ソフトウェア・ベンダー（ISV）およびIoT企業の多数の共通部門を調査してきましたが、その中のイニシアチブは同一とは程遠く、まったく同じ方法で行っている企業はありませんでした。たとえば、他人の家計計画をそのまま使用することはないでしょう。ソフトウェア・セキュリティ・イニシアチブも同様です。BSIMMは、そのままに従うレシピではなく、アイディアを示す一般的なガイダンスとして参照されるべきです。
BSIMMスコアカードで強調表示されているアクティビティがあるのはなぜですか？
12の強調表示されたアクティビティは、最も一般的に実践されていたアクティビティです。
12の基本アクティビティ
| アクティビティ | 説明 |
| [SM1.4] | ライフサイクルのインストルメンテーションを実装してガバナンスの定義に使用する。 |
| [CP1.2] | PII義務を特定している。 |
| [T1.1] | ソフトウェア・セキュリティに関する意識向上トレーニングを実施している。 |
| [AM1.2] | データ分類スキーマとインベントリの作成。 |
| [SFD1.1] | セキュリティ機能の統合およびデリバリー |
| [SR1.3] | コンプライアンス制約の要件への変換。 |
| [AA1.1] | セキュリティ機能のレビューを実施する。 |
| [CR1.4] | 自動化されたツールの使用。 |
| [ST1.1] | QAの実施がエッジ/境界値条件テストに沿ったものであることの確認。 |
| [PT1.1] | 外部ペネトレーション・テスターを使用して問題を特定している。 |
| [SE1.2] | ホストおよびネットワーク・セキュリティの基本事項が実施されていることを確認している。 |
| [CMVM1.1] | インシデント対応の作成または調整を行っている。 |
視覚的な資料があるとわかりやすいです。これをグラフ表示するとどうなりますか？
12のプラクティスについて複数の企業の平均成熟レベルを示した3つのレーダー・チャートは、BSIMMが提供する分析能力の例を示しています。最初のチャートは、BSIMM企業からのデータを示しています（これを「参加企業全体」と呼びます）。2つめのチャートは、参加企業全体と比較して描画されたサンプル企業のデータです。
BSIMMの3つの業界は、規制が厳しい保険、医療、金融サービスの3つに属しています。経験上、金融サービス業界の大企業は、保険および医療業界の企業と比べて1990年代から2000年代初期にかけての法令の変更への対応とSSIの開始がはるかに早いことがわかっています。金融サービス業界の企業数は過去5年間で2倍になり（新しく始められたイニシアチブがBSIMMのデータ・プールに大量に流入している）、評価時点での金融サービス業界のSSGの平均年数は5.4年のままでしたが、保険業界は4.4年、医療業界は4.2年でした。
SSIの成熟にかかる時間は、並べて比較するとはっきり分かります。保険業界には、成熟度の高い企業も含まれていますが、規制の多いこれら3業種のデータを見ると、全体としては保険業界がソフトウェア・セキュリティにおいて遅れをとっていることが分かります。ほとんど例外のない医療業界と比べると、その違いは顕著です。
調査対象組織はすべてソフトウェア・セキュリティの知識を持っていますか？
いいえ。調査対象の各企業のスコアを計算する際に、ある企業の他の企業と比較した相対成熟度と平均成熟度も調査しました。BSIMM12参加企業の大多数のスコアの範囲は31～40で、SSGの平均年数は4.1年です。
幸い、BSIMM調査は年々普及が進んでいます。BSIMMの参加企業は2008年の9社から、2021年には128社に成長し、約3,000人のソフトウェア・セキュリティ・グループ・メンバーと6,000人以上のサテライト（「セキュリティ・チャンピオン」）・メンバーを擁するまでになりました。
BSIMMは規格ですか？
BSIMMは、ISO 27001や卓球の公式ルールのような規格ではありません。BSIMMは、規格ではなく、世界で最も成功しているソフトウェア・セキュリティ対策によって実践されているアクティビティを示します。この意味で、BSIMMは、組織が実際に実践している事実上の標準といえます。頭の中で考えられた理念ではなく、現場で実際に行われている実践方法といえます。
BSIMMの使用方法は？
あなたの組織でソフトウェア・セキュリティ対策がまだ実践されていないとすれば、実践する必要があります。BSIMMはその足がかりになります。ソフトウェア・セキュリティ・グループに何名の従業員が必要か、まず着手すべきことは何か、そして今後数年で行うべきことを特定できます。ソフトウェア・セキュリティ対策がすでに開始されている場合は、BSIMMを使用して、その進捗状況を把握し、今後の計画を策定することができます。
ソフトウェア・セキュリティ・グループとは何ですか？ これは必須ですか？
すべてのBSIMM参加企業には、SSGと呼ばれる、ソフトウェア・セキュリティ専任の社内グループが存在します。SSGなしにBSIMMアクティビティを成功裏に実践している組織は見たことがありません。調査対象の128組織全体で見ると、平均2.59%がSSGメンバーです。これを各参加企業に平均すると、開発者39名当たり1名のSSGメンバーがいることになります。開発者の人数が500名以下の組織の場合、最大割合は51.4%で、最小は0.33%でした。開発者の人数が500名を超える組織の場合、最大割合は14.9%で、最小は0.08%でした。実際の数値では、128企業のSSGの平均規模は22.2名（最小1名、最大892名、中央値7.0名）です。
BSIMMがそれほど重要なら、今までなかった理由は何ですか？
ISV、銀行、医療業界の企業、官公庁などの多くのソフトウェア開発組織にとって、ソフトウェア・セキュリティが問題となってきたのは21世紀に入ってからで、上級幹部レベルで真剣に問題視されるようになったのはここ10年以内のことです。「私たち」は、組織として、マクロ・レベルで何が有効か、お互いの経験を突き合わせて蓄積する水準にやっと到達しました。セキュア・プログラミング、ペネトレーション・テストなどが話題になっていますが、ソフトウェア・セキュリティ対策を形成する最適な方法を特定するにはさらに時間がかかります。BSIMMは、誰でも無料で利用できるオープンな観察型のモデルに対象アクティビティを取り込んでいます。
私は理解しましたが、私の上司は理解していません。ソフトウェア・セキュリティ対策はどのように始まったのですか？
長年のBSIMMで、ITセキュリティが主流となる時代にあったような、ソフトウェア・セキュリティを正当化する必要性を感じています。当時は、ファイアウォールが必要な理由や侵入検知機能によって小さな問題が大きな問題に拡大するのを防止できること、あるいはセキュリティについての従業員の意識を変えることで企業文化が変わることを理解していない経営幹部が存在しました。この時代では、頭では問題を理解している幹部でも、実際に企業で被害が出るまで、導入をためらうという現象が見られました。
BSIMMデータ・プールでは、ソフトウェア・セキュリティ・グループが以下のようなさまざまな状況で予算を獲得していることがわかっています。
- 上級幹部がセキュアなソフトウェアを開発することを宣言して、そのために必要な予算を確保した（セキュリティを最重要課題にするよう指示したマイクロソフトのビル・ゲイツによる2002年のセキュリティ・メモの例）。
- なんらかの形のコンプライアンスを担当している上級幹部グループが、（おそらくは大きな犠牲を伴う失敗を経て）企業のガバナンス・プロセスとしてソフトウェア・セキュリティを必要な経費とみなした。
- ITセキュリティ担当者が、データ漏洩の責任はITセキュリティ部門の責任ではなく、企業のアプリケーションの脆弱性にあることを証明した。
- 影響力のあるソフトウェア・セキュリティ起業家（CIO、CTO、法的またはガバナンス団体）が先導してシステムを構築し、初期の成功を基に実際のプログラムの予算を獲得した。
- 開発グループは、DevOpsへの移行の一環としてさまざまな「セキュリティ」の役割（クラウド・セキュリティ、ビルド・セキュリティ、コンテナ・セキュリティなど）を有機的に発展させ、上級幹部がその取り組みを標準化して、すべての開発グループに知識とプロセスを教え込むプログラムに取り入れました。
今日の問題において困難な点は、上級幹部に問題の重要性を訴えることでは必ずしもなく、自分がその問題解決の責任者として適任であり、かつ具体的な計画を持っていることを納得してもらうことにあるようです。ソフトウェア・セキュリティの責任者は、重大なソフトウェア・セキュリティの問題が発生した場合には解雇される可能性があります。しかし将来の問題解決のためのリソースが現在得られないのであれば、今すぐに退社したほうがよいでしょう。セキュリティの問題に対応しないような組織に未来はありません。自分の能力を活用できる場は他にもたくさんあります。
最新のBSIMM調査で重点が置かれている主なテーマをいくつか教えてください。
注目度の高いランサムウェアとソフトウェア・サプライ・チェーンの寸断により、ソフトウェア・セキュリティに対する注目が高まっている
過去2年間のBSIMMデータを見ると、「オープン・ソースを特定する」アクティビティが61%増加し、参加組織間で「SLAの定型書式を作成する」アクティビティが57%増加しました。
企業はリスクを数値に置き換える方法を学んでいる
過去24か月間に「ソフトウェア・セキュリティに関するデータを内部的に公開する」アクティビティが30%増加していることから、組織がソフトウェア・セキュリティ対策データの収集と公開に対する努力を強化していることがわかります。
クラウド・セキュリティの機能強化
経営幹部の注目度が高まったことと、おそらくエンジニアリング駆動型の取り組みが進んでいる状況が重なった結果、組織はクラウド・セキュリティの管理と責任共有モデルの評価に独自の機能を開発するようになりました。過去2年間で、一般にクラウド・セキュリティに関連するアクティビティ全体で平均36件の新しい観察がありました。
セキュリティ・チームは、リソース、スタッフ、知識をDevOpsプラクティスに貸し出しています。
ソフトウェア・セキュリティ・グループの役割は、ソフトウェア・セキュリティの動作を規定する立場からパートナーシップへと変化し、ソフトウェア配信のクリティカル・パスにセキュリティ対策を組み込む目的でDevOpsプラクティスにリソース、スタッフ、知識を提供していることがBSIMMデータからわかります。
継続的欠陥検出と継続的改善
BSIMM12データは、特定時点で欠陥を検出するのではなく、最新の不具合検出手法を実装し、継続的な監視とレポートを採用する方法を選ぶ企業が増えていることを示しています。
過去2年間に「ソフトウェア・セキュリティに関するデータを内部的に公開する」BSIMMアクティビティが30%増加していることからもわかるように、新しい動向として、ガバナンスの意思決定を裏付けるデータをリーダーシップに提供する必要性が高まっています。ガバナンス・プロセスは現在もほとんど手作業ですが、BSIMM12では、評価対象企業の15%がガバナンスのコード化を目指していることが観察されています。
QAの自動化にセキュリティ・テストが含まれている割合は2倍以上に増加
「QAプロセスにブラックボックス・セキュリティ・ツールを組み込む」BSIMMアクティビティの観測率は、過去2年間で50%以上増加しました。また、「QAの自動化にセキュリティ・テストを追加する」アクティビティの観測率は、過去2年間で2倍以上になりました。
ソフトウェア部品表のアクティビティは367%増加
BSIMMデータを見ると、ソフトウェア部品表（BOM）の作成、ソフトウェアの構築/構成/デプロイ方法の理解、セキュリティ・テレメトリに基づく組織の再配置能力の向上など、ソフトウェアのインベントリに焦点を当てた機能が増加していることがわかります。
多くの組織が包括的な最新のソフトウェアBOMの必要性を強く認識するようになり、これを反映して部品表の機能に関連する「運用部品表を用いてアプリケーションのインベントリを向上させる」BSIMMアクティビティの観測値は、過去2年間で367%増加し、3件から14件に増えました。
「シフト・レフト」から「シフト・エブリウェア」への進化
「シフト・レフト」はセキュリティ・テストを開発プロセスの早期段階に移行することに焦点を当てています。「シフト・エブリウェア」はソフトウェア・ライフサイクル全体にわたってセキュリティ・テストを継続的に行うという考え方を拡張したもので、設計環境でも運用環境でも、できるだけ早い時期に、細分化した迅速なパイプライン駆動型のセキュリティ・テストを行います。
運用環境インベントリの維持という従来のアクティビティから資産の自動検出と部品表の作成に移行するには、コンテナを使用したセキュリティ対策の実施、オーケストレーション、コード化されたインフラストラクチャのスキャンなどの「シフト・エブリウェア」アクティビティの追加が必要です。「運用部品表を用いてアプリケーションのインベントリを向上させる」、「コンテナおよび仮想化環境のオーケストレーションを使用する」、「資産の自動生成を監視する」などのアクティビティのBSIMM観測率の上昇は、すべてこの傾向を示しています。
