6. 脅威モデルテクノロジでの革新

本質的に、脅威モデリングは適切な人々が集まってアプリケーションや IT システムのセキュリティについて考える (そしてできれば改善する) プロセスです。テクノロジはそのプロセスを支援する能力で判断すべきであり、決してそれ自体が目的であってはいけません。

このセクションでは、適切なテクノロジを選択し、作業方法に統合するためのガイダンスを提供するガイドラインをいくつか説明します。テクノロジが脅威モデリングプロセスを最大限に支援します。その逆ではありません。

6.1 適切なツールを選択する

すべての脅威モデラはなんらかのテクノロジを使用します。これは紙切れ一枚のような非常にシンプルなものから脅威モデル専用ツールのように高度なものまであります。ツールを決定する際に常に従うべき基本ルールがひとつあります。ツールがプロセスを支援すべきであり、決してツールに合わせてプロセスを変更してはいけません。このルールに基づき、まずツールの要件を収集する必要があります。

組織内で他の目的にすでに使用されているツールから始めます。おそらくすでに要件を部分的または完全に満たすことができます。

たとえば、アーキテクトは図を作成するためにすでに作図ツールを使用しているかもしれません。脅威モデルプロセスの各問いでは一つ以上のツールを使用しているかもしれません。一般的に、モデルは MS Visio や Diagram.net (旧 Draw.io) のような描画プログラムで作成します。脅威モデル自体はワードプロセッサで文書化し、リスクスコアの計算にはスプレッドシートを使用することがよくあります。

現在使用しているツールセットを特定することで、既存のツールセットに脅威モデルプラクティスを簡単に組み込むことができます。これにより軋轢が減り、組織における脅威モデルプラクティスの導入が促進されるはずです。組織はそれぞれ異なり、その組織のニーズに合わせて異なる方法で脅威モデルプラクティスとプロセスを実装しています。つまり脅威モデルプロセスのある成熟度に対して 'fix' した明確なツールのリストはありません。

ツールは要件を満たすものであるため、脅威モデルプロセス時に使用する際にツールの使用について文書化することが重要です。

ツールは組織に合わせて調整すべきです。必要な脅威モデル数の規模に適合しているべきです。これらの脅威モデルの複雑さや脅威モデルプロセスの成熟度に対応すべきです。もちろん、ツールは利用可能な予算内に収まるべきです。

例として、最も安価で入手しやすいツールの一つであるフリップチャートについて説明します。脅威モデリングに不慣れな組織でフリップチャート、ホワイトボード、マジックペーパーを使用するのには、良い理由がいくつかあります。モデルの作成はさまざまな利害関係者が協力して行う作業です。ホワイトボードを囲んで、すべての利害関係者がマーカーを手に取り、モデルに変更を加えることができます。そうすることで利害関係者の積極的な参加を促し、システムスコープに関するコンセンサスを得やすくなります。同じ理由は脅威モデル時に利害関係者が一緒に作業する他の時間にもあてはまります。脅威モデルはこれらの利害関係者間のコンセンサスであるため、滅亡のシナリオ、スコープ、モデル、脅威、緩和策、リスクなどについて話し合う必要があります。フリップチャートは脅威モデルの旅を始める際にどのような組織においても脅威モデルを作成する最初の段階で使用できる安価なツールです。組織が成熟しても非常に妥当なツールであり続けるでしょうが、脅威モデルを更新していくためにデジタル版のモデルから開始するツールの必要性がおそらく出てくるでしょう。フリップチャートはそのための最も理想的なツールではないので、最初の段階で作成した脅威モデルを、既存のモデルの更新を必要とする重要な機能を追加することになった際に、組織で置き換えられるでしょう。

リモート操作を使用して脅威モデルを作成することは確かに可能ですが、これを効率的な方法で行うには特定のツールとチーム内のある程度の経験が必要です。

6.2 ツールの結果を処理する

脅威モデルの主な目的は意思決定者が客観的でリスクベースのアプローチを使用して、システムに対する脅威を緩和できるようにすることです。

しかし、脅威モデリングを行う理由は他にも数多くあります。これらの理由は以下のとおりです。

  • 利害関係者への意識向上のため

  • デューデリジェンスを文書化するため

  • システムに関する文書として提供するため

  • セキュリティレビューやペネトレーションテストのような他のプラクティスにインプットを与えるため

  • 他のシステムや脅威モデルで学んだ教訓のフィードバック

  • 脅威モデリングに関する知識を共有するため

  • …

これらの要件をすべてカバーするには、脅威モデルがさまざまなグループの人々からアクセスできる必要があります。中には脅威モデルの特定の部分のみにアクセスできる必要がある人もいます。

最初の脅威モデルの作成を開始すると、これらのセッションの結果を永続化する必要があります。そのため選択するツールは以下の二つの要件を満たす必要があります。

  1. 脅威モデリング時に発生する利害関係者間の会話を許可し促進する

  2. 脅威モデルを永続化し、簡単に更新でき、すべての利害関係者が利用できるようにする。脅威モデルにはモデリング成果物と裏付けとなる証跡が含まれている。

脅威モデルを永続化するためのツールを評価する際、運用上のセキュリティも保証されなければなりません。脅威モデルには未解決のセキュリティ問題という形で機密情報が含まれており、そのアクセスは可能な限り制限されるべきです。このため運用上のセキュリティと脅威モデリングに対する他の要件との間に不和となる領域が生まれます。両方の要件セットをどのように扱うかについてのビジョンを決定し、ツール選択時のガイドラインとして提供すべきです。

上記の二つの要件と運用上のセキュリティを組み合わせると、さまざまな利害関係者と (部分的な) 情報を共有できる場所やツールを複数用意することになるかもしれません。

6.3 脅威モデリング手法への統合

まず 6.1 章で規定したルールを思い出してみましょう。ツールがプロセスを支援すべきであり、決してツールに合わせてプロセスを変更してはいけません。このルールに基づき、まずツールの要件を収集する必要があります。

組織ではすでにいくつかのツールが使用されている可能性があります。可能であれば、これらのツールを再利用することでプロセスを実装する軋轢を制限し、コスト (潜在的なライセンスと学習曲線の両方で) を制限できます。

Dev(Sec)Ops 18 プロセスを見て、ここで使用されている典型的なツールをレビューすると、調和のためのいくつかの可能性を見出すことができます。

  • いくつかのアーキテクチャ図が既に存在しているかもしれず、潜在的に再利用できる可能性があります。これらの図は脅威モデリングのために拡張を必要とする傾向があります。ほとんどの作図ツールはこれをうまく処理できます。

  • 開発者がスプリントやストーリーなどの情報を置く wiki のようなツールがすでに存在するかもしれません。これはシステムのドキュメントの最新版かもしれませんし、脅威モデルはそのドキュメントの一部とみなすことができます。

  • 脅威モデルから得られるアクションのフォローアップ (承認された緩和策の実装など) には、他の開発活動に使用されるのと同じチケット追跡ツールを使用すべきです。

  • セキュリティ上の問題 (例えばペネトレーションテストからの) をスコア化するために使用したリスク計算手法は脅威モデリング時に再利用し、異なるリスク同士を容易に比較できるようにすべきです。

ツールを再利用するか、そのプロセスを支援するツールを入手することで、脅威モデルツールが Dev(Sec)Ops パイプライン内に適合することを確認します。脅威モデルプロセスのアウトプットは開発成果物とみなすことができます。この最善の例は脅威モデルをコードとして扱うことです。コードとしての脅威モデリングはすべてを 'as code' とするトレンドに沿ったものです。脅威モデルのさまざまな要素は多くの場合、人間と機械の両方が読めるテキスト形式で記述されます。ここから、一部のフレームワークではドキュメント生成、自動テスト、自動リスク計算などができます。このような脅威モデリングのスタイルは継続的な開発プラクティスに非常に適しています。脅威モデルプロセスもまた、開発チームにおけるツールサポートと統合に重点を置いた継続的なプロセスです。

このドキュメントを執筆している時点 (2020) では、モデリングをコードとして扱うことは成熟した専門分野ではありません。さらに、コードとしてのインフラストラクチャ (infrastructure as code) やコードとしての脅威モデリング (threat modeling as code) などを行う準備ができている組織はそれほど多くありません。したがって、脅威モデリングプラクティスとアジャイルプロセスおよびツールの両方に最高レベルの成熟度を持つ組織に予約された、このプレイブックでのオプションのステップであると考えています。

Previous5. 脅威モデルプロセスの強化

Last updated