脅威モデリングは、ソフトウェアとアプリケーションを保護するための非常に効果的な手段ですが、実際にそれを行っている組織はほとんどありません。 しかし、今日のコンピューティングおよびセキュリティ環境では、脅威のモデル化がこれまで以上に必要になっています。
クラウドベースの分散システムと機能横断型のアジャイル ソフトウェア開発チームが、サイロ化されたチームによって構築および運用されるモノリシック システムに取って代わりました。 その過程で、ソフトウェアははるかに複雑になり、脅威も複雑になりました。 攻撃者は、従来の検出手段を回避するために戦術を変更しました。 たとえば、多くの攻撃はマルウェアを配信しなくなり、代わりに資格情報の侵害に焦点を当てています。 また、攻撃者は行動する前に、企業のネットワーク内に何ヶ月も留まることができます。 IBMの「データ侵害レポートのコスト組織が侵害を特定して封じ込めるまでに平均 287 日かかることがわかりました。
企業はその必要性を認識しています。 あ 2021 年セキュリティ コンパス調査 中規模および大規模企業の 79% が脅威のモデリングを優先事項と見なしているが、設計の初期段階でモデリングを行っているのは 25% だけであることがわかりました。 また、開発したアプリケーションの 10% に対して脅威のモデリングを行っているのは 90% だけです。
業界として、脅威のモデル化をソフトウェア開発の標準的な手法にし、開発チームとセキュリティ チームの両方が協力できる方法で導入し、時間の経過とともに肯定的な結果と改善を示す方法で実装する必要があります。 そしてすべては、IT 運用やセキュリティ サークルではあまり耳にすることのない言葉、共感から始まります。
文化の変化
脅威モデリングの価値を理解することと実際にそれを実行することの間には、多くの理由があります。たとえば、セキュリティ チームと開発チームの間のコミュニケーションの欠如や、最初の取り組みが混乱してうまくいかない場合に脅威モデリングをあきらめる傾向があります。望ましい結果を生み出します。
多くの場合、セキュリティ チームは、セキュリティ コントロールの適用を開発チームとの間の一方通行のように見なすことができます。単に開発者に何をすべきかを伝えるだけの問題です。 しかし、それは間違った足で始まっています。 組織は、各チームが他のチームから学べるスキルを持っていることを認識する必要があります。 結局のところ、セキュリティの専門家を開発者スペースに配置すると、彼らは失われてしまいます。
この考え方を変えるには文化的な変化が必要であり、それは共感を価値提案と見なすことから始まります。 この人間的な側面が最前線に来て、より多くの人々が私たちの知識を豊かにすることに関与する必要があります. セキュリティ チームは次のことを行う必要があります。 開発者が働く環境に感謝する、ソフトウェアを迅速に開発して提供するというプレッシャーにさらされています。 開発チームは、セキュリティ チームがコンテナなどのフレームワークやアクセスを制御する方法、セキュリティ ポリシーに適用できる知識を理解するのに役立ちます。
チームがコラボレーションを行ったり来たりしているとき、チームはお互いから学んでいます。 その点に到達するには時間がかかります。 会議やプロセスの統合から始まり、試行錯誤を経て、最終的にツールの統合に移行します。 誰もが互いのドメインの基本的な理解を持っている成熟度に達すると、ナレッジ ベースのモデル化や一緒にマップする概念のグラフの作成など、より高度なレベルの脅威モデリングに移行できます。
しかし、それには安定したプロセスが必要です。そうしないと、費用がかさみ、混沌とし、厄介な人的問題が発生します。
脅威モデリングを改善するための 3 つのステップ
共同作業の雰囲気を作るには、XNUMX つの重要な要素があります。
コーチング: これは、開発者が脅威モデリングの重要性を理解するのに役立ちます。 新しい従業員のオンボーディングから始めることができます。 経歴や資格に関係なく、会社でセキュリティがどのように処理されているかを彼らが知っていると思い込まないでください。 彼らが文化を理解していることを確認してください。
コラボレーション: 協力とコラボレーションの文化は、チームに奉仕したいという姿勢を持つ CISO とともに、企業のリーダーシップから始まります。 時間はかかるかもしれませんが、リーダーシップ レベルでモデル化する必要があります。
統合: 協力の要素は、進行中のプロセスである統合に取り組んでいます。 目標は完璧ではなく、時間をかけて改善し進化させることです。
このアプローチを機能させるための鍵は、 特に結果を見て、指標を適用する、「脆弱性を減らす」など、個人の働き方の詳細を評価しようとするのではなく. 結果は開発者やセキュリティの問題ではなく、全員の問題です。
私の経験では、30 日、60 日、90 日の明確な計画を立て、各段階で予想される結果を説明することが有用であることがわかりました。 計画は、漸進的な成長を示し、協力して行う必要があります。 これらの結果を測定する必要がある場合、または目的もなく漂流してしまうことになります。
共感が鍵
セキュリティ コミュニティとして、私たちの責任は次のとおりです。 開発者が脅威モデリングを受け入れるのを支援する. 私たち対彼らではありません。 時間の経過とともに進化する統合アプローチの一環として、セキュリティと脅威のモデル化について彼らに考えてもらう必要があります。
管理テクニックとしての共感は、その環境を作り出すのに役立ちます。 共感とは説明責任がないことだと考える人もいるかもしれません—誰かの立場や考えを理解することはなんとなく柔らかいことだと思います—しかし、それは実際には反対の結果をもたらします. それは、私たちが切実に必要としているコラボレーションを発展させます。
