脅威をモデル化する

GitHubでは、ソフトウェアをどうセキュアにできるかについて時間をかけて考え、開発することに取り組んでいます。その主たる側面として、脅威のモデル化が挙げられます。これには、セキュリティチームとエンジニアリングチームが連携してシステムについて話し合い、最終的にはシステムのセキュリティをさらに高めるアクションアイテムを生成することが含まれます。脅威のモデル化は、セキュリティチームとエンジニアリングチームとのコミュニケーションの円滑化、セキュリティレビュープロセスを能動的に行うようにする、信頼性とセキュリティの高いシステム設計の実現に役立っています。

脅威のモデル化とは

脅威のモデル化に対するGitHubのアプローチを掘り下げる前に、まず、「脅威のモデル化」とは何かについて認識を合わせておきましょう。

GitHubでは、脅威のモデル化は特定のツールまたは一連の成果物として形になるとは限りません。これは、セキュリティチームとエンジニアリングチームとの間で、新しいシステムや既存のシステムについて継続的なディスカッションを促進するためのプロセスです。脅威のモデル化とは、セキュリティに対する協力的な取り組みであり、新しいサービスまたは既存のサービスの設計およびタスク計画の評価と検証を行います。この取り組みには、サービスに悪影響を及ぼしかねない潜在的なセキュリティ脆弱性について、構造的に考えることが必要になります。

脅威のモデル化について議論する場合は、少なくとも以下のことを目標としておくべきです。

まず、提案されるアーキテクチャまたは既存のアーキテクチャを掘り下げ、全員がシステムの仕組みを理解していることを確認します(少なくともこれが必要なのは、もうおわかりのとおりです。そして必ず文書化してください)。
次に、対象領域全体を包括的に評価し、セキュリティ侵害が最も起こりやすいポイントを明らかにします。これが主たる成果物です。
個々のセキュリティ侵害ポイントに対して実装する緩和戦略を策定します。無限のリソースを持つ人はいないので、優先順位を付けることになるでしょう。

脅威のモデル化プロセスとは

脅威のモデル化を実行するタイミングの決定

通常、GitHubの脅威のモデル化は、各機能チームと定期的に行うほか、アーキテクチャに大きな変化をもたらす新機能をリリースする前にも行います。機能に対して行われるエンジニアリングの量に応じて、その頻度を数か月ごとなどに増やしたり、年に一度などに減らしたりします。ソフトウェアレビューの頻度がすでに定められている場合は、既存のプロセスに組み込むことで、新しいセキュリティプロセスの追加に順応しやすくなります。どのようなタイミングにせよ、ガイドラインを定めて柔軟に対応してください。

脅威モデルの構築

脅威のモデル化は、通常は共同で取り組むことなので、製品のエンジニアリングチームとセキュリティチームが集まり、アーキテクチャおよび潜在的なセキュリティの問題点について話し合います。セキュリティチームは、効果的な脅威のモデル化に関する文書と例を、エンジニアリングチームへ事前に提供します。また、各エンジニアリングチームにはシステムのかなりの部分をカバーするモデルを事前に作成してもらい、1回の脅威モデリングの会話の一部としてレビューできるように依頼します。これらの期待値を早期に設定しておくことで(また、事前の準備をこなしておくことで)ミーティングを効果的に進めることができます。

プロセスとディスカッションのほうが特定のアウトプットよりも重要ではあるものの、GitHubでは、MicrosoftのThreat ModelingツールかOWASPのThreat Dragon(いずれも無料)で脅威モデルを開発するようエンジニアリングチームに要請しています。これらのツールを使用することで、チームは脅威モデルにおいて重要な情報を明確に示せるようになります。たとえば、API、信頼境界、依存関係、データストア、認証機構などがこれに含まれます。これらのファイルは、チーム間である程度の整合性を確保する以外にも、さまざまなセキュリティコンプライアンス要件に対応しなくてはならない場合には、監査員と共有できる重要な担保としての役割を果たします。

脅威モデルのレビュー

脅威モデルをレビューする段階になると、一般的に、2部に分けた1時間のセッションを設定します。各セッションの冒頭5～10分間は、エンジニアリングチームがレビュー対象のシステム設計を理解するために費やされます。ここで、全員が理解を共有していることを確認し、以前に作成した脅威モデルにおけるあいまいな点(使用される技術や設計上の癖など)を明確にします。全員の足並みがそろったところで、セキュリティのディスカッションに入ります。

セキュリティディスカッションのこの段階では、フレームワークを使用して、さまざまな脆弱性クラスに体系的に対処することが有益です。私たちがよく使っている手法として、MicrosoftのSTRIDEモデルがありますが、これはアプリケーションに潜む一般的な攻撃ベクトルの頭文字をとったもので、Spoofing (なりすまし)、Tampering (改ざん)、Repudiation (否認)、Information Disclosure (情報漏洩)、Denial of Service (サービス拒否)、Escalation of Privilege (権限の昇格)を表します。全体的なシステムを見ながらこれらのクラスをたどっていくと、セキュリティチームは分析対象のシステムを包括的に捉え、最も発生する可能性の高い脅威を確実に網羅できるようになります。そして残りの時間で、STRIDEを順番に取り上げて会話を発展させ、システムのその他の部分を明らかにしていきます。

セキュリティの潜在的な脆弱性または設計上の欠陥が見つかると、セキュリティチームがその脆弱性や欠陥とともに、考えうる修正策をメモします。このメモは、セッション終了後にエンジニアリングチームが潜在的な変更点をリストアップできるように作成します。脅威のモデル化がGitHubで広く取り入れられるにつれ、チームはシステムの開発に取り組みながらセキュリティチームと連携できるようになりました。これによって、潜在的な問題をあらかじめ把握し、開発作業に取り掛かる前にアーキテクチャの主な変更に対処できるようになりました。一方で、セキュリティチームの場合は、セキュアな設計原則を通じて、より優れた防御を徹底的に配備できるようになりました。

セッションの終了時刻が近くなったら、主な成果と、チームが行うべき改善点を見直し、それらについて追跡アイテムを作成します。参加者にはサマリーが配布され、アクションアイテムにさらに肉付けできるようフォローアップの質問をすることができます。

脅威のモデル化から学んだこと

前述のとおり、組織のセキュリティを意識した文化を促進する脅威のモデル化には、いくつかのメリットがあります。私たちの場合は、主に以下の3つのメリットを見出すことができました。

システム全体のセキュリティ向上

一堂に会し、システムに関して包括的に話し合うことは、基盤となるシステムについて全員でディスカッションを行う絶好の機会です。チーム間で知識を共有することで、全員が環境内のシステムに関する知識を深めることができました。また、脅威モデルのレビュー時に検出された問題に対して脆弱性の緩和戦略を策定するうえでも役立ちました。これによって、組織全体でのセキュリティ意識が高まりました。

プロアクティブな設計ガイダンス

脅威のモデル化が成熟すると、“シフトレフト”、つまり開発プロセスの早い段階に組み込み、製品の出荷よりも前にセッションを実施するようになりました。多くの場合、セキュリティチームは問題を特定すると同時に対応する必要があります。組織において、脅威のモデル化のタイミングをプロセスの早い段階にシフトすると、将来的に脆弱性を引き起こしかねないシステム設計を回避するよう、エンジニアリングチームを誘導できることもあります。

セキュリティチームとエンジニアリングチーム間のコミュニケーションの向上

このメリットは、エンジニアリングチームとセキュリティチームに大きな変化をもたらしました。脅威のモデル化によって両チームが定期的に集まる機会を設けられるようになったため、相互に連絡を取りやすくなりました。

まとめ

GitHubでの脅威のモデル化を向上させるための主な取り組みについて説明しました。そのプロセスの簡単な概要は以下のとおりです。

脅威のモデル化プロセスを既存の開発ライフサイクルプロセスに統合し、可能であれば自動化する
全員が準備を整えた状態で臨む
STRIDEなど、定義された仕組みを用いてリスク領域を体系的に網羅する
具体的なアクションアイテムを持ち帰る
フォローアップ

こうしたステップを踏むことで、開発中のシステムのセキュリティを高め、エンジニアリングチームと(リリース前に)積極的に関与し、ソフトウェア開発に携わるチーム間のつながりを強化できることがわかりました。

脅威モデルの実行方法

脅威のモデル化の、最高な(または最悪な)取り組みについてぜひお聞かせください。Twitterでハッシュタグ「#GitHubThreatModeling」を付けてツイートしてください。