DevSecOpsのスピードが求められる世界で、脅威モデリングはどう活用できる？

DevSecOpsの目的は、高品質なソフトウェアをより速く開発することです。しかし脅威モデリングのプロセスは、時間がかかり複雑で、多くの組織がソフトウェア開発ライフサイクル（SDLC）を遅らせると考えています。ソフトウェア開発プロセスを妨げずに脅威モデリングのセキュリティ上のメリットを得るには、どうすればよいのでしょうか？

この記事では、脅威モデリングを振り返り、DevSecOpsプロセスに自然に組み込む方法を解説します。

脅威モデリングとは？

脅威モデリングでは、システムの動作設計と、サブシステム間の境界を越えてデータがどのように流れるかを調べます。そして、攻撃者に悪用される可能性のある攻撃ポイントと、その攻撃方法を特定します。最後に、システムとそのデータを保護するための対策を設計します。

第一人者のAdam Shostack氏によると、脅威モデリングでは次の問いを立てます。

• 何を構築するのか？システム内のデータの流れ、データが通過する境界、各接続に使われる技術を評価します。

• 何が起こりうるのか？接続部分を悪用するあらゆる手段を検討します。

• それにどう対処するのか？それぞれのエクスプロイトに対する防御策を設計します。

• 適切に実施できたか？最後の、そして最も重要な問いです。プロセスを振り返って検証し、作業に終わりはなく、常に改善の余地があることを思い出させてくれます。

その後、チームは脅威リスクに優先順位を付け、開発に組み込みます。

脅威モデリングはいつ実施すべき？

脅威モデリングを実施する理想的なタイミングは、アプリケーション開発のアーキテクチャ設計段階、つまりSDLCの最初期です。脅威を早く特定するほど、攻撃経路を阻止する対策を効率よく考案できます。

最初からアプリケーションにセキュリティを組み込むのが理想ですが、レガシーアプリケーションであっても、脅威モデリングのメリットを得るのに遅すぎることはありません。SDLCのどの段階で実施しても、関係者全員にとって有益な取り組みです。

脅威モデリングの歴史

脅威モデリングの初期の試みは、1990年代にアタックツリーの概念とともに始まりました。その後、MicrosoftのLoren Kohnfelder氏とPrerit Garg氏が「The Threats to Our Products」という文書を発表しました。この文書は、脅威モデリングプロセスを正式に記述した最初のものとして広く認識されています。

それ以来、業界ではOpen Web Application Security Project（OWASP）のような団体が中心となり、主要な脅威とその内容、対処方法を評価してきました。OWASPは、Software as a Service（SaaS）のAPIに対応するため、デジタルAPIセキュリティについても同様の脅威評価を公開しています。

Yahoo、Uber、First American Financialなどで、何百万件ものユーザー記録が攻撃者に盗まれています。今日、あらゆる組織がデジタル脅威を認識する必要があります。2020年のセキュリティレポートは、憂慮すべき状況を示しています。

• 2020年には18,000件を超える脆弱性が記録され、その約4分の1が深刻度の高いものでした。

• 企業がデータ侵害の修復に支払った費用は、平均386万ドルでした。

• マルウェア攻撃とランサムウェア攻撃は、それぞれ358％、435％増加しました。

脅威モデリングのヒント

脅威モデリングのプロセスは非常に複雑になることがあります。由緒あるSTRIDE手法では、主な攻撃タイプごとに個別の技術分析を行うことを推奨しています。

• なりすまし（Spoofing）：何者かになりすまして認証を侵害する。

• 改ざん（Tampering）：システムを侵害し、さらなる悪用を可能にする。

• 否認（Repudiation）：攻撃の痕跡を隠して検知を妨げたり、攻撃中のログを正常に見えるよう偽装したりして、意図を隠し、攻撃を継続させる。

• 情報漏えい（Information Disclosure）：システム内のあらゆる場所から機密データを抜き取る方法を見つけ、機密性を侵害する。

• サービス拒否（DoS）：システムを適切に動作させるために必要なリソースを意図的に枯渇させ、ユーザーのシステムアクセスを妨げる。

• 権限昇格（Elevation of Privilege）：システムを欺いてアカウントに過剰な権限を付与させ、システムへのアクセスを拡大することで認可を侵害する。

データフロー図（DFD）、STRIDE、そしてそれらに類する新しい手法は、次のような問いに答えるための枠組みを提供します。

• 「何を構築するのか？」DFDは、システムとそのさまざまな信頼境界を図示する方法の一つです。セキュリティ脅威を理解するための第一歩となります。

• 「何が起こりうるのか？」STRIDEでは、システムの構成を踏まえて各攻撃タイプを検討し、この問いに焦点を当てます。

たとえば2019年、Kubernetes API Serverに対するサービス拒否攻撃では、APIの「ペイロード」に大量のデータを渡せる抜け穴が悪用され、システムの処理が滞りました。

この脅威を軽減する方法には、次のようなものがあります。

• すべての呼び出しに対するペイロードサイズの上限

• 特定のユーザーまたはIPアドレスに対するAPI呼び出し回数の上限

これにより、API Serverに対する今後のDoS攻撃を防ぐことができました。

こうした取り組みにはシステム機能の詳細な調査が必要で、攻撃の種類ごとに実施しなければなりません。対策は可能ですが、調査、設計、構築、テスト、デプロイには時間がかかります。

従来の脅威モデリングがDevSecOpsの課題となる理由

従来の脅威モデリングでは、IT担当者やサイバーセキュリティの専門家を含むすべての関係者が参加する分析会議が必要です。こうした会議では、脅威やその緩和策に関する知識や情報が共有され、参加者全員にとって有益です。

しかし、会議自体に時間がかかり、多くの人を何日も拘束することがあります。そのため、すべてのスプリントの前に開催することはできません。ソフトウェア開発ライフサイクルの高速化を目指すDevSecOpsの文化とも相いれません。

開発を高速化する、DevOpsでよく見られるトレンド：

• ビルドパイプラインのできるだけ上流で、自動化とテストを推進する（「シフトレフト」）。

• 自動化の対象はアプリケーションコードだけではありません。新しい技術により、システムインフラストラクチャもコードで定義してテスト可能になっています。

• こうした自動化によって継続的インテグレーション／継続的デリバリー（CI/CD）が加速し、機能やバグ修正をより頻繁に、より高い信頼性でデプロイできます。

その結果、ソフトウェア開発はますます高速化し、2～4週間ごとに新しいコードを本番環境へデプロイするチームもあります。このようなサイクルの中で、時間のかかるセキュリティ会議を開く余裕はあるでしょうか？

DevOpsプロセスに活かすための脅威モデリング教育

IBMのセキュリティ専門家Brandon Jeanmarie氏が強調するように、脅威モデリングの考え方をセキュアなSDLCに取り入れるには、教育が鍵となります。しかし、大人数での長時間の会議を頻繁に開くことはできません。そのため同氏は、顧客と連携する際、開発チームのメンバーに必要なタイミングで教育する「ジャストインタイム」方式を推奨しています。

• 脅威モデリング は難しくありません。開発者やマネージャーが何を実現できるか理解できるよう、説明する機会を活用しましょう。システム開発の現在の状況から、「今」できることを始めます。

• システムに関わるすべての人が学びから恩恵を受けます。各チームメンバーの役割に合った脅威モデリングの知識を提供します。理解を深めれば、スプリントのストーリー計画で解決策の検討に参加し、適切に優先順位を付けられます。

• 教育も「シフトレフト」できます。脅威モデリングへの認識を、パイプラインのできるだけ上流に移します。これによりDevSecOpsで優れたプラクティスが生まれ、脅威の特定と緩和をできるだけ早い段階から取り入れられます。

• 脅威モデリングツール で「右に拡張」できます。サードパーティ製ツールを使えば、SDLCの後半段階でも脅威の自動検知や緩和の自動化が可能になります。本番環境まで保護を続けることもできます。

Jeanmarie氏は、状況や役割に応じた教育によって「セキュア・バイ・デザイン」の考え方が育まれ、組織のDevSecOpsが強化されると結論づけています。頻繁に大規模な会議を開かなくても実現できます。こうした知識が文化として根付けば、脅威への対処が自分の番になったとき、誰もが力になれます。

アジャイルのストーリー設計に脅威モデリングを取り入れる4つのステップ

セキュリティ推進者のAlyssa Miller氏は、脅威モデリングをさらに「左」へ進めています。同氏は、脅威モデリングをDevSecOpsにより自然に組み込む方法を検討し、次のように提案しています。

脅威モデリングの範囲を、各ユーザーストーリーの要件に絞ります。DevSecOpsで「左」へ移せる限界に近いアプローチです。

この手順では、ストーリー分析の話し合いにビジネスユーザーを加えます。ストーリーの要件は技術的な詳細より上流にあるため、有効です。ビジネスユーザーに次の質問をします。

• 新機能に関わる重要な資産は何か？

• 重要な資産ごとに、起こりうる最悪の事態は何か？

話し合いを通じて、誰もが理解できる平易な言葉でストーリーに記載するセキュリティ要件が自然に明らかになります。たとえば、次のようなものです。

• 重要な機能F1およびF2を、不正使用から保護する。

• 非公開データXYZを、漏えいから保護する。

• 購入Pの金銭取引を、通信中の盗難から保護する。

こうした平易な記述をストーリーに追加すると、開発パイプラインの下流で一連の作業が始まります。

このように脅威モデリングのプロセスを見直すことで、同氏はその定義をより簡潔にまとめました。「システムに対する起こりうる脅威を特定し、セキュリティ対策の設計に活かすこと」です。

Miller氏は、こうすることでDevSecOpsの文化をSDLCの最初期に取り入れ、開発チーム全体が継続的な改善という全体目標の中で、状況に応じた脅威モデリングを実践できると考えています。誰もがセキュリティを意識し、その意識をスプリント計画会議やその後のすべての活動に活かすことで実現できます。

1. 計画：セキュリティ要件をストーリーに盛り込む。

2. 構築：脅威緩和策（セキュリティコントロール）をSDLCに組み込む。

3. テスト：脅威緩和のユースケースを含むストーリーを作成し、テストケースにする。

4. デプロイ：テストケースを実装するモニターを作成し、アラートを設定する。

Miller氏は、このプロセスによってDevSecOpsのスピードを損なわずに脅威モデリングを取り入れられると結論づけています。

まとめ

DevSecOpsの文化では、SDLCを自動化可能な単位に分解し、サイクルの早い段階で品質を高める「シフトレフト」と、ソフトウェアデリバリーパイプライン全体をカバーするツールで「右に拡張」することを重視します。脅威モデリングと、それを要件定義からSDLCに組み込む方法をチーム全体に教育することで、脅威への認識がDevSecOpsのあらゆる段階に浸透し、各工程に活かされます。