2. 利害関係者からの承諾
関係するすべての利害関係者の承諾を得られて初めて、脅威モデルはその目的であるリスクの軽減とセキュリティの向上を実現できます。具体的には、プレイブックを実施するために以下のリソースが必要となります。
脅威モデルを作成するために関与する人の時間
脅威モデルの専門知識 (特に始めたばかりの場合)
結果として生じる脅威に対処するための時間、リソース、権限
これらは脅威モデリングでリスクを管理することに経営陣の承諾と確約を得るために重要です。これらを順に見ていきましょう。
2.1 関与する人と時間の割り当て
脅威モデルの作成に直接または間接的に関与する人の数を過小評価しがちですが、彼らに協力してもらうには彼らの懸念に対処する必要があります。そのためには、まずコストがどれくらいかかるのか、また脅威モデルに時間を費やす際の障害となりうるものは何かを理解する必要があります。このリストでは脅威モデリング支持者については言及していないことに注意してください。彼らが脅威モデリングを行う動機は想定されているためです。
経営陣
貴重なチームメンバーを脅威モデリング演習に割り当てる必要があり、他の活動が遅れる可能性があります。
投資収益率を確認したいが、脅威モデルの付加価値を認識していない可能性があります (特に脅威モデリングが組織にとって新しいものである場合) 。
潜在的なすべての脅威が明示されることを躊躇する可能性があります。つまり "それについて知っていれば、私はそれについて何かしなければならないだろう" ということです。
アプリケーションオーナー
既存の脅威の兆候がすでにあり、それらの脅威を明示的に文書化することを望まないかもしれません。
厳しいロードマップに直面しており、そのロードマップに潜在的に長い緩和策のリストを追加することに躊躇します。
脅威モデリングワークショップを支援するために、ある程度の時間を費やす必要があります。
アーキテクト
脅威モデルは試験のようなものだと感じるかもしれません。外部のチームがアーキテクチャをレビューし、評点を付けるのです。
脅威モデリングワークショップを支援するために、ある程度の時間を費やす必要があります。
開発者
脅威モデルはコードレビューのようなものであり、自分のセキュアコーディングスキルに評点を付けられると感じるかもしれません。
脅威モデルによって開発者が特定のセキュリティスキルを持っていないことを浮き彫りにされることに躊躇するかもしれません。
脅威モデリングワークショップを支援するために、ある程度の時間を費やす必要があります。
セキュリティエンジニアや DevOps エンジニア
脅威モデルはレビューのようなものであり、現在のセキュリティギャップが浮き彫りになることに躊躇するかもしれません。
脅威モデリングワークショップを支援するために、ある程度の時間を費やす必要があります。
プロジェクト管理者
すでにいくつかの (おそらく非常に厳しい) 締め切りに直面しており、プロジェクトロードマップにさらに作業を追加することを躊躇します。
脅威モデリング演習とその結果によって、プロジェクトロードマップが完全に頓挫することへの不安があります。
このような議論を和らげ、脅威モデリングが利害関係者の利益にもなることを納得させるためには、まず利害関係者の懸念に耳を傾け、それを理解することが必要です。
経営陣
セキュリティに積極的な姿勢をとっていることを示します。
GDPR コンプライアンスやプライバシーバイデザインやセキュリティバイデザインなどの論拠として役立ちます。
潜在的なすべての脅威が明示されることを躊躇する可能性があります。つまり "それについて知っていれば、私はそれについて何かしなければならないだろう" ということです。
ISO 27001 などの情報セキュリティ管理システム (ISMS) の役立つ部分です。
リスクの明確なリストを持つことで、リスクベースのセキュリティ管理が可能になります。経営陣は最初に最も高いリスクに対処するためにセキュリティ予算を投資していることを示すことができます。
アプリケーションオーナー
リスクの明確なリストと提案された緩和策があることで、リスクベースのセキュリティ管理が可能になります。
脅威モデルは追加のセキュリティ予算を要求するためのツールとして使用できます。
アーキテクト
脅威モデルはレビューではありませんが、アーキテクチャを改善するための建設的なアドバイスにつながるはずです。
アーキテクチャの他の部分や他のアプリケーションドメインでインスタンス化できる再利用可能なセキュリティパターンにつながるかもしれません。
開発者
脅威モデルはレビューではありませんが、建設的なアドバイスとして役立つはずです。
追加のセキュリティ予算 (セキュリティに特化したトレーニングなど) を要求するための原動力として使用されるかもしれません。
セキュリティエンジニアや DevOps エンジニア
脅威モデルはレビューではありませんが、建設的なアドバイスとして役立つはずです。
追加のセキュリティ予算 (セキュリティに特化したトレーニングなど) を要求するための原動力として使用されるかもしれません。
プロジェクト管理者
脅威モデルはすべての利害関係者が共通認識を持ち、セキュリティに対する一貫した見解があることを確認するための理想的な演習です。
脅威モデルは追加のセキュリティ予算を要求するためのツールとして使用できます。
2.2 脅威モデリングの専門知識を注入
脅威モデリングを成功させるために取得する必要がある二つ目の要素は、関連する専門知識です。第 2 章では、脅威モデリングのスペシャリストを見つけることと人材を育成することの重要性について述べます。関連する専門知識を得るためには、三つのアプローチが考えられます。順に見ていきましょう。
自前で行うアプローチ
脅威モデリングに足を踏み入れたばかりの組織では、本を読んだり、無料で利用できるオンラインリソースにアクセスしたりすることで、脅威モデリングの専門知識を習得することが一つの選択肢となります。特に多額のセキュリティ予算がない場合や現在の必要性が低い場合にはこのような方法が有効です。
このアプローチの利点はすぐに始められることと、多くの準備や予算を必要としないことです。しかしながら、その反面として、始めたばかりの時には脅威モデリングは厄介であることが挙げられます。セキュリティの専門知識を持たない人の場合、特にそうです。その場合、最初のアドホックな脅威モデリングの試みが失敗すると、他の利害関係者が脅威モデリングアプローチの設定にさらに投資するための信用が損なわれてしまう可能性があります。また、このアプローチは大規模な組織には適用できません。
したがって、アドホックなアプローチを始めるのは、関係者が過去に何かしらのセキュリティに触れたことがあり、実験する熱意がある (失敗しても構わない) 場合に限ることをお勧めします。それ以外の場合には、外部のスペシャリストを雇うことから始めたほうがよいかもしれません。
スペシャリストの雇用
脅威モデリングアプローチの採用を開始するための優れたかなり簡単な方法は、チームと密接に協力しながらスペシャリストに脅威モデルを作成してもらうことです。この方法では、チームは脅威モデリングがどのように実行されるかを実際に見ることができ、最初の脅威モデルが成功することがより確実になります。
このアプローチの利点はアドホックなアプローチよりもリスクが大幅に低いことと、かなり短い時間でより多くの信用と、より広範な脅威モデリングアプローチを採用したいという意欲を生み出せることです。さらに、同じスペシャリストを雇うことで他のチームの脅威モデルのフォローアップを行うことができるため、規模の拡大も十分に可能です。このアプローチの欠点はアドホックなアプローチよりも多額の予算が必要であることと、ポートフォリオに数十ないし数百のアプリケーションを持つ大規模な組織には自動的に適用できないことです。
したがって、スペシャリストを雇うことを検討すべきであるのは、脅威モデリングを始めたばかりで経験を積みたいと考えている組織や、ポートフォリオに少数のアプリケーションしかない小規模な組織となります。さまざまなチームに脅威モデリングを体系的に導入したいと考えている大規模な組織の場合には、外部の脅威モデリングトレーニングプログラムが適しています。
脅威モデリングトレーニング
脅威モデリングトレーニングプログラムでは、トレーナーを雇い、脅威モデルを作成するための最初のコアチームをトレーニングします。研修生は組織内で脅威モデリングのスペシャリスト (あるいはエバンジェリスト) としての役割を担うことができるモチベーションの高い人材であるべきです。
このアプローチの利点は、拡張性が非常に高く、組織が脅威モデリングを採用して定着させることが完全にできる成功確率が最も高いことです。しかし、反面として、トレーニング後に実際に初期の脅威モデルを作成する必要があるため、結果が出るまでに時間がかかります。また、先行投資の額も大きくなるため、脅威モデリングの価値がまだ立証されていない組織ではハードルが高いかもしれません。
2.3 脅威モデリングの費用対効果
最後に、組織内で持続可能な脅威モデリングの取り組みを行う上で極めて重要なことは、費用対効果 (ROI) を実証し、経営陣のコミットメントを獲得することです。脅威モデリングアプローチはその組織またはその製品のセキュリティが実証可能な改善をもたらす場合にのみ ROI を示すことができます。
考慮すべき点は以下のとおりです。
セキュリティの向上につなげるためには、脅威モデリングアプローチにより関連する利害関係者に明文化された推奨事項を示す必要があります。誰も存在を知らないファイル共有上の文書は決して ROI につながることはありません。
変化をもたらすためには、脅威モデルの推奨事項は現実的で実行可能なものである必要があります。推奨事項はプロジェクトのタイミング、予算、専門知識、その他の制約を超過している場合、変化をもたらすことはできず ROI にもつながりません。脅威モデル担当者は推奨事項を示す前にプロジェクトの制約を十分に理解することが重要です。
脅威モデリングにより変化が効果的であることを示すために、脅威モデルで示された緩和策や推奨事項は新しいユーザーストーリー、バグ修正、JIRA チケットなどの開発成果物と明確にリンクする必要があります。脅威モデリングの影響を受けるプロジェクト数、ユーザーストーリー数、チケット数を測定できれば、組織全体での脅威モデリングの採用レベルとその効果をより簡単に把握できます。その結果、ROI の実証が容易になります。
最後に、変化がポジティブなものであることを示すために、脅威モデリングによってもたらされた変化を、脅威モデリングを実施したシステムの稼働後に報告されたセキュリティバグやインシデントの数とリンクする必要があります。考慮すべき重要な点は、脅威モデリングの直接的な結果として報告されたセキュリティ問題の数 (この数は多くなるはず) と、事後に報告されたセキュリティ問題の数 (この数は少なくなるはず) を区別することです。脅威モデリングがより多くのセキュリティ問題を検出し、修正する役割を担っていることを明確にすることで、ROI を明確に示すことができます。
Last updated