BSIMM11は、実際の企業から収集したソフトウェア・セキュリティ・アクティビティに関する調査を基に、 ソフトウェア・セキュリティ・イニシアティブを導くのに役立つガイドを作成します。
ソフトウェア・セキュリティ・イニシアティブ(SSI)の進化に関する年次報告書であるセキュア開発成熟度モデル(BSIMM)は、それ自体が成熟しつつあります。今週公開された最新版は11回目のレポートです。
変わらないものもあります。基本的な目標は、10年以上前の当初の目標のままです。著者が頻繁に述べているように、この「研究室から逃れた科学実験」は、組織が効果的なSSIを開発するというしばしば危険な道を進むのを助け、作成されたSSIを測定するために使用できる無料のツールを提供するように設計されています。
しかし、その目標を達成するためにBSIMMチームは多くの変化を消化し理解する必要があります。それは年々難しくなっています。それにより、BSIMMはかなり成長し、2009年のわずか9つの組織と110の活動の初期プールから、複数の業種の211の組織の詳細な観察を通じて、ソフトウェア・セキュリティの進化を追跡し、121の活動を含むようになりました。
そうすることで、BSIMMはソフトウェア・セキュリティ・イニシアチブを測定するために利用できる最良のツールとしての評判を確立しました。決して物事を行うための決まった方法を規定することによってではありません。BSIMMは、「今何が起こっているか」のガイドです。 今年のレポートは、主に9つの業種で、複数の地域にまたがる130の参加企業の観察に基づいています。
これは、昨年の主に8つの業種での122の参加企業から増えています。この変更は、単に8社を追加したのではありません。データ・プールを最新に保つために、27社が追加され、19社が削除されています。
BSIMMは、組織が実際に時間とお金を費やしている活動を調査します。 この現実世界の景色(誰かのアイデアによるベストプラクティスではなく、実際のプラクティス)は、BSIMM11に含まれる121のソフトウェア・セキュリティ対策のアクティビティそれぞれについて書かれた説明に反映され、またこれにより組織で確実に観察される新しい活動が追加されます。
これまでに、特にソフトウェア・セキュリティに携わっている場合は、BSIMMについて聞いたことがあるのではないでしょうか。 コピーをダウンロードしたこともあるかもしれません。常に無料で誰でもダウンロードできます。 クリエイティブ・コモンズ表示 – 継承3.0 ライセンスの下で、データは毎年公開されており、多くの組織がBSIMMを社内で使用しています。
そして今、BSIMM11が発表されました。新しいコピーを入手する時です。BSIMMは完全にデータ駆動型であるため、このレポートは過去に読んだものとは異なります。これは、ソフトウェア・セキュリティの世界が進化しているためです。 BSIMM11の変化は、その進化を反映しています。その変化の中で:
BSIMM11では、さらにイベント駆動型のセキュリティ・テストを実装し、デプロイ可能なオブジェクトのリスク・データを公開するためのアクティビティを追加します。これらは、進行中のDevOpsとDevSecOpsの進化、および従来のソフトウェア・セキュリティ・グループとの交点を、直接反映しています。
実際、今年のレポートでは、ガバナンス主導のセキュリティ活動を行っている組織とエンジニアリング主導のセキュリティ活動を行っている組織は、どちらも等しくBSIMMを使用して機能を向上させることができることがわかりました。
BSIMM11の他の重要なメッセージは次のとおりです:
Cigitalが2006年頃に「シフト・レフト」という概念について書き始めたとき、それはニッチな聴衆に向けられていました。しかし、この用語は急速に製品ベンダーやセキュリティ会議のマントラになり、プレゼンテーションやパネル・ディスカッションを支配しました。サンフランシスコで開催された2020年2月のRSAカンファレンスでは、DevSecOpsデイズのトラックのどのセッションにおいても、これを何度も聞くことになりました。
重要なのは、SDLCが終了するまで待ってセキュリティの脆弱性を探し始めないことです。
しかし、この概念は、「左に(だけ)シフトする」のように、文字通りに解釈されることを意図したものではありませんでした。
シノプシスのプリンシパル・サイエンティストであり、BSIMMの最初からの共著者でもあるSammy Migues 氏は、次のように述べています。「私たちが本当に意味したのは、より正確にはシフト・エブリウェアと言うべきもので、必要な作成物が利用可能になり次第、最高の忠実度で、可能な限り迅速にアクティビティを実施することです。」
「例えば、実行可能なコードが手に入ったらすぐに動的解析(DAST)を実行し、ソフトウェア実行環境を定義また起動したらすぐに構成レビューを実施し、コードをデプロイするとすぐに実行中のシステムに動的に組み込まれた依存関係を示す本番エージェントからコンポジション解析のイベントを収集します。」
「これにより、アクティビティを実施するタイミングが今より早くなる場合(シフト・レフト)もあれば、遅くなる場合(シフト・ライト)もよくあり、おそらくあらゆるところにあり得ます。」
おそらく、それはセキュリティの民主化と呼ぶことができます。つまり、成功の手段をすべての人が利用できるようにすることです。 BSIMMで追跡されている一部の組織では、中央には主にガバナンスに焦点を当てた小さなソフトウェア・セキュリティ・グループしかなく、CloudSec、ContainerSec、DeploymentSec、ConfigSec、SecTools、OpsSecなどの責任者とともに、エンジニアリング・チームがソフトウェア・セキュリティの取り組みの多くを実行するケースが増えています。
それは、功罪相半ばする結果を生じています。アジャイルであるため、これらのチームはアクティビティを迅速に実行できます。これは良いことです。一方、管理チームが組織のリスクへの影響を評価するには速すぎる可能性があります。これはあまり良くありません。中央集権的なフトウェア・セキュリティの取り組みとエンジニアリング・ソフトウェア・セキュリティの取り組みを、まとまりがあり、説明可能で、正当化できるリスク管理プログラムに完全に調和させた組織はほとんどありません。
それでも、エンジニアリング・グループは、機能提供の速度が優先事項であることを明確にしています。つまり、ツールチェーン内で目に見えない形で繰り返し実行されるセキュリティ・テスト・ツールは、無料のオープンソース・ツールであったとしても、利益よりも摩擦を生み出す、または生み出しているように見える、より徹底的な商用ツールよりも、今日の価値が高い可能性があります。メッセージ:私たちの速度を低下させない限り、私たちはバリュー・ストリームにセキュリティを確保したいと考えています。
最後に、一部の組織では、セキュリティが品質の一部になり、信頼性の一部になり、レジリエンスの一部になり、多くのエンジニアリング・グループの運用目標になりつつあります。
「『脆弱性が発覚したらパッチを出す(penetrate and patch)』という言葉だけを話すソフトウェア・セキュリティ・リーダーは、先に進んだエンジニアリング・チームにより、バリュー・ストリームからまもなく『パッチ』されるでしょう。」とMigues氏は述べています。
従来のソフトウェア・セキュリティ・チャンピオン(開発チーム内から、または開発チームに割り当てられたセキュリティ擁護者)は、より個人的なレベルで機能する傾向がありました。すなわち、ブラウンバッグ、個人間の会話、電子メール、スプレッドシート、ダッシュボード、および反抗的なチームからの時折の公の呼びかけなどです。
それが、ソフトウェアを期待値に一致させるためのツールチェーン・センサー(ライブラリの使用、特定の欠陥の除去、コーディング規約など)や、事前承認された構成と構成チェッカー(コンテナ使用時など)、あるいは再利用可能なセキュリティ・ライブラリーなど、セキュリティ知識を直接コードとして提供するチャンピオンに変身しつつあります。
これらは、いわば「構造的」セキュリティを確立しています。 開発者が安全な構造内でコードを作成すると、より安全なソフトウェアを構築できます。
クラウドに移行することの利点は大いに宣伝されているため、よく知られています。 安価で、分散した従業員のコラボレーションが容易になり、さらに機動性が向上することにより、チームメンバーはどこからでも作業できます。これは、パンデミックが長引く場合には事実上必須です。
ただし、クラウドを効果的に使用するということは、セキュリティ・アーキテクチャ、機能のプロビジョニング、および従来はローカルで行われていたその他のソフトウェア・セキュリティ・プラクティス領域の少なくとも一部をクラウド・ベンダーにアウトソースすることも意味します。
また、BSIMMに記載されているように、「ユーザー企業が使用するセキュリティ・ソフトウェアを提供する責任は100%クラウド・プロバイダーにありますが、ソフトウェア・セキュリティに対する責任は100%ユーザー企業にあります。」
「プライベート・データセンターでソフトウェア・セキュリティを適切に実施していなかった組織は、クラウドでもソフトウェア・セキュリティを適切に実施していない可能性があります。」
デジタル・トランスフォーメーションの取り組みは広く行き渡っており、ソフトウェア・セキュリティが組織のあらゆるレベルでその重要な要素となっているこが現実です。
エグゼクティブ(SSI)レベルでは、組織はテクノロジー・スタック、プロセス、および人員を、自動化優先の戦略に移行する必要があります。
SSGレベルでは、チームはアナログ債務を削減し、文書とスプレッドシートをコードとしてのガバナンスに置き換える必要があります。
エンジニアリング・レベルでは、チームはインテリジェンスをツール、ツールチェーン、環境、ソフトウェア、その他すべての場所に統合する必要があります。
これらのハイライトを超えて、基本的なソフトウェア・セキュリティ・アクティビティは、より簡単にかつより困難になっています。ソフトウェアインベントリは、以前はアプリケーション名が記載されたExcelスプレッドシートでした。その後、(ほとんどが古くなった)構成管理データベースになりました。
現在、組織は、アプリケーション、API、マイクロサービス、オープンソース、コンテナ、グルーコード、オーケストレーションコード、構成、ソースコード、バイナリコード、実行中のアプリケーションなどのインベントリを必要としています。自動化は役に立ちますが、可動部品は膨大な数になります。
Migues氏が述べているように、「脅威モデリングもまた、(フェデレーションすることが)より簡単になり、(いつ実行するかを知るのが)より困難になっています。パッチ適用は、より簡単になる場合(100のアプリケーションに対して1つのコンテナ)もあれば、より困難になる場合(CI / CDツールチェーン、グルーコード、自家製ツールなどを構成するすべてのものを誰が所有しているかを知ること)場合もあります。」
注目に値する業界の他の大きなトレンドがあります。 「特に、逸話的に、現在の世界と政治情勢は、ソフトウェア・セキュリティのプロセス、テクノロジー、およびリソースに大きな変化をもたらしました」とMigues氏は述べています。
一例として、多くの組織での採用が大幅に減速し、既存のスタッフとテクノロジーで今年と来年の両方の目標を達成することが義務付けられています。
「主に、これはプロセスの自動化、人がプロセス・ブロッカーになるのを防ぐためのセンサーを介した何らかのインテリジェンスの適用、そして高速化はすべて(望ましいすべてのセキュリティ・テスト)がデリバリー・ライフサイクルのインバンドで実行できることを意味しないということの文化的受容の開始における、大幅な加速として実装されていると考えています」とMigues氏は述べています。
BSIMM11には多くの、はるかに多くの、詳細があり、ガバナンス、インテリジェンス、セキュア・ソフトウェア開発ライフサイクル(SSDL)タッチポイント、およびデプロイメントの4つのドメインにグループ化された、12のプラクティスにグループ化されたアクティビティについて詳細にレポートします。
アクティビティは、参加組織が行っていることと、SSIを有効にするために使用しているツールの種類を示しています。おそらくもっと重要なのは、BSIMMが、現在のデータ・プールで各アクティビティが観察される頻度を示すことです。これにより、参加している組織とそうでない組織、すべての組織が、業界内およびすべての業種にわたって、他の組織にとって何が有用であるか、またはおそらく役に立たないかを確認できます。
BSIMMは、組織がSSIを開始するのを支援するだけでなく、開始したばかりの「導入期」から、経営陣のサポートと期待を含めて稼働している状態を意味する「成熟期」、そして既存のセキュリティ機能を微調整してリスク選好に合わせ、希望の状況に合わせて投資を適切なサイズにすることを意味する「最適化期」まで、SSIの成熟度を評価する方法も提供します。
組織がその道のりのどこを進んでいようとも、BSIMMは組織が目標を達成するのに役立つロードマップを提供します。