ここには、BSIMMに関してよくあるご質問が記載されています。完全版をお読みになるには、BSIMMドキュメントをダウンロードしてください 。
よくあるご質問
BSIMMとはなんですか？
BSIMM（「ビー・シム」と発音します）は、Building Security In Maturity Modelの略です。BSIMMは、ソフトウェア・セキュリティ・イニシアチブの進捗状況を確認し、長期的な実行計画を立てるために構成された、実践的なソフトウェア・セキュリティ・イニシアチブの調査です。
ソフトウェア・セキュリティが必要な理由はなんですか？
ソフトウェア・セキュリティとは、攻撃されている間もセキュリティ上安全なソフトウェアを構築することです。長年にわたるネットワーク・セキュリティ侵害のレビューからわかったことは、セキュリティを当初から組み込んでソフトウェアを開発することが、ソフトウェアの保護につながるということです。また、セキュリティはモノではなく資産であるため、暗号やパスワードなどのセキュリティ機能をソフトウェアに追加するだけでは攻撃に対する耐性を得るソフトウェア・セキュリティは達成できません。
ソフトウェア・セキュリティを考慮する必要があるのはどんな人ですか？
業務でソフトウェアを開発および使用する組織（現代社会ではすべての組織）には、大量のIDデータの漏洩や、多額の賠償責任、悪意のあるユーザーによる機密情報の入手を許さないソフトウェアが必要です。ソフトウェアの信頼性を高める唯一の方法は、セキュリティ機能を組み込んで開発することです。つまり、ソフトウェアを使用するすべての組織にBSIMMが必要なのです。
BSIMMの特長はなんですか？
弊社は、すべて、実際のソフトウェア・セキュリティ・イニシアチブを調査し観察した結果からBSIMMを開発しました。BSIMMによって、何をするべきかはわかりませんが、他社が何をしているかがわかります。ソフトウェア・セキュリティ・サイエンスに対するこの「観察と報告」によるアプローチは、個人的な経験に基づいた規範的アプローチと大きく異なります。
どんな組織が調査対象に含まれていますか？
最新の評価では、平均で122社の参加企業が4.53年間にわたってソフトウェア・セキュリティを実施しました（2019年6月の時点で、1年未満～19年間）。122社すべてが、ソフトウェア・セキュリティ専任の内部グループを任命してソフトウェア・セキュリティ・グループ・イニチアチブを成功させることに合意しました。SSGの規模は平均で13.1名（最小1名、最大160名、中央値6.0名）で、他のサテライトグループ（開発者、アーキテクト、およびソフトウェア・セキュリティに直接従事し促進に努めている組織の従業員）は平均で51.6名（最小0名、最大1,500名、中央値0名）で構成されます。参加組織の開発者の平均人数は3,804.2名（最小5名、最大100,000名、中央値900名）で、SSGの開発部門の平均割合は1.37%（中央値0.61%）です。
全体では、BSIMMには、1,596社のSSG参加社と、468,500名の開発者が開発したソフトウェア（約175,000のアプリケーション）をセキュリティ保護する6,298名のサテライト参加者で構成されます。
ソフトウェア・セキュリティの責任を追うべきは誰ですか？
今回調査されたソフトウェア・セキュリティ・イニシアチブを管轄する幹部の役職は、コーポレート・セキュリティ担当アシスタント・バイス・プレジデント、アプリケーション・セキュリティ担当部長、セキュリティ保証担当部長、情報セキュリティ担当バイス・プレジデント、アプリケーション・リスク管理担当バイス・プレジデント、シェアードサービス担当上級部長、ソフトウェア・セキュリティ・エンジニアリング担当マネージャー、エンタープライズ・ソフトウェア担当上級部長、インフラストラクチャ/セキュリティ担当上級部長、グローバル情報セキュリティ・イノベーション担当上級部長、セキュリティ・テストグローバル責任者、システム開発担当システム・マネージャー、セキュリティ・アーキテクト、製造オペレーション担当執行役員、情報セキュリティ・オペレーション担当マネージャー、情報システム担当マネージャー、組み込みシステム/サイバーセキュリティ担当リーダーなど、多岐にわたります。どこにSSGが配置されているかについて広範囲にわたって精査しました。特に、参加企業122社中71社のSSGがCISOによって、またはCISOを直近の上級経営幹部とする人間によって運営されています。17社がCTOを直近の上級経営幹部とし、6社がCIO、7社がCSO、4社がCOO、2社がCRO、1社がCAOの下にSSGを配属しています。14社のSSGは技術または製造部門の組織に所属しています。
BSIMMには何が含まれますか？
BSIMMを構成する主な機能はソフトウェア・セキュリティ・フレームワークです。このフレームワークはガバナンス、インテリジェンス、SSDLタッチポイント、導入の4つの領域で構成され、それぞれに12のプラクティスがあります。
- ガバナンス：戦略と指標 、コンプライアンスとポリシー、トレーニング
- インテリジェンス：攻撃モデル、セキュリティ機能と設計、標準と要件
- SSDLタッチポイント：アーキテクチャ解析、コード・レビュー、セキュリティ・テスト
- 導入：ペネトレーション・テスト、ソフトウェア環境、コンフィグレーション管理と脆弱性管理
BSIMM10では、プラクティスごとに関連するアクティビティが用意され、合計119のアクティビティがあります。調査では、各アクティビティが何回観察されたかを追跡しました。以下は結果データです（各アクティビティを解釈するには119の各アクティビティが詳細に説明されている、BSIMMドキュメントをダウンロードしてください）。
アクティビティごとに説明と、組織での実施方法を示すための実例が示されています。例は特定のアクティビティを実行する唯一の方法ではなく、ソフトウェア・セキュリティの現実を示す意図で挙げられています。
セキュリティ・アクティビティ数が119とはずいぶん多いですね。
ご安心ください。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年のままでしたが、保険業界は3.2年、医療業界は3.1年でした。SSIの成熟にかかる時間は、並べて比較するとはっきり分かります。保険業界には、成熟度の高い企業も含まれていますが、規制の多いこれら3業種のデータを見ると、全体としては保険業界がソフトウェア・セキュリティにおいて遅れをとっていることが分かります。ほとんど例外のない医療業界と比べると、その違いは顕著です。
調査対象組織はすべてソフトウェア・セキュリティの知識を持っていますか?
いいえ。調査対象の各企業のスコアを計算する際に、ある企業の他の企業と比較した相対成熟度と平均成熟度も調査しました。現在のプールでのスコアの範囲は[5, 83]です。
幸い、BSIMM調査は普及が進んでいます。今回報告されたデータ全体の量は、初回の発表値に比較して約38倍に拡大しました。30企業のサンプル・サイズを超えた時点で、統計分析が適用され、統計的に有効な結果が抽出できています。
BSIMMは規格ですか?
BSIMMは、ISO 27001や卓球の公式ルールのような規格ではありません。BSIMMは、規格ではなく、世界で最も成功しているソフトウェア・セキュリティ・イニシアチブによって実践されているアクティビティを示します。この意味で、BSIMMは、組織が実際に実践している事実上の標準といえます。頭の中で考えられた理念ではなく、現場で実際に行われている実践方法といえます。
BSIMMの使用方法は?
あなたの組織でソフトウェア・セキュリティ・イニシアチブがまだ実践されていないとすれば、実践する必要があります。BSIMMはその足がかりになります。BSIMMを使用すれば、ソフトウェア・セキュリティ・グループに何名の従業員が必要か、まず着手すべきことは何か、そして今後数年で行うべきことを特定できます。ソフトウェア・セキュリティ・イニシアチブがすでに開始されている場合は、BSIMMを使用して、その進捗状況を把握し、今後の計画を策定することができます。
BSIMMの利用料金は?
BSIMMは無料で利用できます。BSIMMは、Creative Commonsライセンスでリリースされています。つまり、他のモデルと同様に「オープン」なものであり、社内文書のたたき台として、または独自のモデル作成のための公開されたデータとしてご利用いただけます。このような場合、BSIMMを参照して作成したことを明示してください。つまり、BSIMMのクレジット表示を行ってください。ご不明な点がございましたら、お問い合わせください。
ソフトウェア・セキュリティ・グループとは何ですか? これは必須ですか?
すべてのBSIMM参加企業には、SSGと呼ばれる、ソフトウェア・セキュリティ専任の社内グループが存在します。SSGなしにBSIMMアクティビティを成功裏に実践している組織は見たことがありません。調査対象122組織全体で見ると、開発部門の平均1.37%がSSGメンバーです。これを各参加企業に平均すると、開発者73名当たり1名のSSGメンバーがいることになります。SSGの最大割合は20%で、最小率は0.02%でした。実際の数値では、122企業のSSGの平均規模は13.1名（最小1名、最大160名、中央値6.0名）です。
BSIMMがそれほど重要なら、今までなかった理由はなんですか?
ISV、銀行、医療プロバイダー、官公庁などの多くのソフトウェア開発組織にとって、ソフトウェア・セキュリティが問題となってきたのは21世紀に入ってからで、上級幹部レベルで真剣に問題視されるようになったのはせいぜいここ10年以内のことです。「私たち」は、組織として、マクロ・レベルで何が有効か、お互いの経験を突き合わせて蓄積する水準にやっと到達しました。セキュア・プログラミング、ペネトレーション・テストなどが話題になっていますが、人をソフトウェア・セキュリティ・イニシアチブに動員する最適な方法を特定するにはもっと時間がかかります。BSIMMは、誰でも無料で利用できるオープンな観察型のモデルに対象アクティビティを取り込んでいます。
私は理解しましたが、私の上司は理解していません。ソフトウェア・セキュリティ・イニシアチブはどのように始まったのですか?
長年のBSIMM調査で、ITセキュリティが主流となる時代にあったような、ソフトウェア・セキュリティを正当化する必要性を感じています。当時は、ファイアウォールが必要な理由や侵入検知機能によって小さな問題が大きな問題に拡大するのを防止できること、あるいはセキュリティについての従業員の意識を変えることで企業文化が変わることを理解していない経営幹部が存在しました。この時代では、頭では問題を理解している幹部でも、実際に企業で被害が出るまで、導入をためらうという現象が見られました。
BSIMMデータ・プールでは、ソフトウェア・セキュリティ・グループが以下のようなさまざまな状況で予算を獲得していることがわかっています。
- 上級幹部が「セキュアなソフトウェアを開発する」と宣言して、そのために必要な予算を確保した（セキュリティを最重要課題にするよう指示したマイクロソフトのビル・ゲイツによる2002年のセキュリティ・メモの例）。
- なんらかの形のコンプライアンスを担当している上級幹部グループが、（おそらくは大きな犠牲を伴う失敗を経て）企業のガバナンス・プロセスとしてソフトウェア・セキュリティを必要な経費とみなした。
- ITセキュリティ担当者が、データ漏洩の責任はITセキュリティ部門の責任ではなく、企業のアプリケーションのセキュリティ脆弱性にあることを証明した。
- 影響力のあるソフトウェア・セキュリティ起業家（CIO、CTO、法的またはガバナンス団体）が先導してシステムを構築し、初期の成功を基に実際のプログラムの予算を獲得した。
- 開発グループは、DevOpsへの移行の一環としてさまざまな「セキュリティ」の役割（クラウド・セキュリティ、ビルド・セキュリティ、コンテナ・セキュリティなど）を有機的に発展させ、上級幹部がその取り組みを標準化して、すべての開発グループに知識とプロセスを教え込むプログラムに取り入れました。
今日の問題において困難な点は、上級幹部に問題の重要性を訴えることでは必ずしもなく、自分がその問題解決の責任者として適任であり、かつ具体的な計画を持っていることを納得してもらうことにあるようです。ソフトウェア・セキュリティの責任者は、重大なソフトウェア・セキュリティの問題が発生した場合には解雇される可能性があります。しかし将来の問題解決のためのリソースが現在得られないのであれば、今すぐに退社したほうがよいでしょう。セキュリティの問題に対応しないような組織に未来はありません。自分の能力を活用できる場は他にもたくさんあります。
最新のBSIMM調査で重点が置かれている主なテーマをいくつか教えてください。
DevOpsはソフトウェア・セキュリティに影響をもたらす。BSIMMのデータは、DevOpsの動向、CI/CDツールおよびデジタル・トランスフォーメーションの発展が、企業のソフトウェア・ポートフォリオに対するソフトウェア・セキュリティ手法に影響を与えることを示しています。
エンジニアリング・ドリブンという新しいセキュリティ文化の波。BSIMM10は、ソフトウェア・セキュリティの取り組みを中央のSSGからのトップダウンではなく、開発および運用チームからのボトムアップによってエンジニアリング主導で進める新しい波に見られるような、SSI文化の変化を正式に反映した最初の調査です。エンジニアリング主導のセキュリティ文化は、一部の組織では有意義なソフトウェア・セキュリティの取り組みを確立し、成長させる手段であることが示されていますが、ほんの数年前までその実現は困難でした。
BSIMM はSSIの進化への対処に役立つ。BSIMMのデータは、常により多くのアクティビティに対応することに努めるよりも、既に実施しているアクティビティを深め、幅を広げ、拡張することに重点を置いた方が、長期的に見て組織は向上し、成熟度を高めることができることを示しています。
