ThoughtWorksのサイバーセキュリティに焦点を当てたテクノロジーコンサルタントであるJim Gumbley氏は、先頃、MartinFowler.comに、チームのリモートおよびオンサイトの脅威モデリングセッションを促進するためのテンプレートの記事を公開した。Gumbley氏は、チームが新しい機能を構築する際に、ビジネスパートナと一緒に継続的な脅威モデリングを主張する。彼は、これにより、実際の組織のリスクに対処する優先順位の高いストーリー、受け入れ基準、アーキテクチャのエピック、スパイクが生成されると書いている。
Synopsys Software Integrity GroupのセキュリティアドボケイトであるDerek Handova氏も、DevOps.comに先頃、セキュアSDLCの一部として段階的なセキュリティ保証を求めることに関するDevSecOpsの観点についての記事を書いている。Handova氏は、セキュリティテストのシナリオを自動化すると、開発者がコードをチェックインするたびに「一貫したレベルのアプリケーションセキュリティテスト」を行うことができると主張した。彼は、機能提供の定期的なリズムをサポートする上で、セキュリティを含むSDLCの必要性について次のように書いている:
DevOpsの下で、一部の開発組織は現在、毎日、毎週、または隔週のリズムでソフトウェアリリースを行っています。しかし、彼らはまだ古いアプリケーションセキュリティモデルに取り組んでいます。その結果、開発とセキュリティのテストが同期しなくなる可能性があります。毎週リリースされるソフトウェアに対して2週間の侵入テストを実施することはできません。これらの組織は、SDLCで効果的なセキュリティ保証を必要としています。これは、優れた、迅速な、早期の、そして何よりも自動化されたものです。
Gumbley氏は、チームが設計中に新機能によってもたらされるリスクを特定して対応するのに役立つ15〜90分のワークショップのテンプレートを提供する。彼は、アイスブレイクに「セキュリティ関連の頭の体操」を脅威モデリングワークショップで開くことを勧める。ワークショップのGumbley氏の形式は、技術的なソリューションを視覚化し、「邪悪なブレーンストーミング」を通じてリスクを引き出す。彼はセッションを次の質問に答える3つの主要な活動に分ける:
- 「何を作ろうとしていますか」 - これにより、ソリューションの共有技術ダイアグラムが作成される。
- 「何がうまくいかないのですか?」 - 技術的な脅威は、ブレーンストーミング活動を通じて引き出される。
- 「何をしますか?」 - これにより「バックログに追加された優先付けられた修正」が生成される。
Gumbley氏は、リモート脅威モデリングセッションは「誰もが仮想的に参加できるように」計画する必要があると書いた。彼は、ThoughtWorksで「Mural、Miro、Google Jamboard、Google Docsなどの」コラボレーションツールと組み合わせたビデオ会議ツールを使用して成功したことを共有した。
Gumbley氏は、「演習前に非同期にダイアグラム」を技術的に作成することにより、リモート脅威モデリングセッションを短くすることを勧める。彼は「概念の一般的な理解」と「ダイアグラムの記号、データフローの矢印、デジタル付箋の色の説明」をリモートで促進する必要性を強調している。Gumbley氏は、この視覚化にはユーザ、システム境界、ネットワーク境界に関する詳細を含める必要があると書いている。彼はいくつかの例を提供した。
Gumbley氏は、チームの開発者が「ソフトウェア設計を探索するための図を描くのを快適にする」ため、提案されたソリューションの視覚化を支援することを勧めている。彼は、ファシリテーターがシステムの「信頼できるパス」を視覚化する際に「これらの確立されたスキルを活用する」ことを提案している。彼は書いた:
攻撃者は、正当なユーザーが行うのと同じ経路を使用して、システムを中心にピボットすることがよくあります。違いは、彼らがそれらを乱用することです。
Gumbley氏は、チームが「プロダクトオーナ、ビジネスアナリスト、デリバリーマネージャ」と一緒に脅威をモデルすることが重要であると書いている。彼は、これが「リスクに全体的に対処するのに役立ち、チーム全体が学ぶのに役立つ」と提案した。そのような協力がなければ、Gumbley氏は、脅威の「価値は広く理解されない」ため、脅威に対処できないと主張した。彼は「サイバーセキュリティの損失が発生した場合、それはビジネス上の損失である」として、セキュリティの共有される利害を読者に思い出させた。
脅威をブレインストーミングするとき、Gumbley氏はSTRIDEなどのフレームワークを使用することを提案した。STRIDEは、IDスプーフィング、汚染された入力、情報セキュリティ、特権昇格などの要因に関連するリスクを検討するようにチームに指示する。Gumbley氏の推奨は「データフローラインをたどって」悪用可能な「技術的メカニズム」とフローを特定することだった。このような脅威は「デジタル付箋」を使用してキャプチャできる。彼はまた、結果として得られる学習の感度について警告し、次のように述べている:
脅威モデリングの出力は、さまざまな理由で機密情報を表すため、保護する必要があります。
Gumbley氏は「リモートワークは疲れる」と書き、「より小さなグループを作成して、出力を統合する」ことを推進した。彼は「2回の小さなセッションは、1回の大きなセッションよりも優れており、より持続可能である」と提案した。
緩和策の優先順位付けを支援するために、Gumbley氏は、特定された脅威に対するドット投票を提案した。彼は、これが「グループ内の多様な視点を反映して、低投資に対して適切なリスク決定をもたらす」と示唆した。
Handova氏は、企業や開発チーム全体に「万能のDevSecOpsプロセスはない」と書いている。彼は、あらゆるリスクについて、チームは「適切なレベルのセキュリティ保証とセキュリティカバレッジを提供する」必要があると書いている。Handova氏は、この決定により、セキュリティテストへの投資の対応を決定するかどうかが決まる可能性があると書いている。つまり「DevOpsワークフロー内で自動化されているか、帯域外で実行されているか、またはその2つの組み合わせで実行されているか」だ。
Handova氏は、「コーディングアクティビティを急ぐこと」を優先してセキュリティをバイパスすることを回避するために、「開発者の摩擦」を最小限に抑える必要があると警告した。彼は、セキュリティの問題を「開発者がまだコードについて考えている間に、より早く、より簡単に」キャッチすることの価値について書いている。Handova氏は、テスト自動化を使用して「開発者が後日コードコンテキストを覚えていないリスク」を緩和することに焦点を置いた。セキュリティリスクを特定して優先順位を付けるために、Gumbley氏は各反復内で脅威モデリングを勧める:
...脅威モデリングを「少しずつ」行います。このように作業する場合、各脅威モデリングセッションは小さく、影響はほとんどありません。しかし、それらを行うことの累積的な効果は大きな影響を及ぼします。繰り返しごとにこれをやり直すことがわかっている場合は、すべてを一度に実行しようとするインセンティブが少なくなり、現在最も重要な作業に優先順位を付けるインセンティブが高くなります。