たかげべら

Written by Takahito KIKUCHI

OWASP Sendai ミーティング #56 に参加し「脅威モデリング」を体験してきました

2023年4月26日に開催された「OWASP Sendai ミーティング #56」に参加しましたので、今回はその話をします。私個人としては9月に開催された同イベント以来の参加となります。

owaspsendai.connpass.com

まず「OWASP Sendai」とは何者か

今回のイベントの主催団体である「OWASP Sendai」は、アメリカに本部を置く Web アプリケーションセキュリティに関する非営利のオープンソース・ソフトウェア (OSS) コミュニティ「OWASP (The Open Worldwide Application Security Project)」の仙台支部団体になります。2017年ぐらいから活動を開始し、年4回ほど、ソフトウェア開発者とその周辺の方を対象とした Web アプリケーションセキュリティに関する勉強会を仙台市内で開催し、地域内での情報効果や知識の共有を継続的に行っています。

owasp.org

活動を開始して少し経過したあたりから OWASP Sendai さんには定期的に顔を出してまして、今やすっかり常連扱い...されているかもしれない。

今回のテーマ「脅威モデリング」とは何か

本イベントのテーマとなっている「脅威モデリング (Threat Modeling) 」とは、情報システムを抽象的な視点から要素分解し、その要素ごとに起こりうる脅威を洗い出す取り組みのことを言います。既に実装された、もしくは実装を意識した内容ではなく抽象的な内容から要素分解を進めるのが、現実のシステムを対象とした情報セキュリティ上のアプローチとの大きな違いで、ビジネスロジックレベルで脅威とその発生要因を洗い出す点から、シフトレフト*1やプロアクティブ・セキュリティ*2の1手段と考えることができます。

加えて、脅威モデリングは後述するコラボレーション性の高い実施プロセスから、開発者教育やチームビルディングに適していると言われており、イベント内で聞いた話では、Microsoft がこれを新人教育のトレーニングに組み込んでいるとか何とか。また、検索エンジンで「脅威モデリング」で調べると、製品・サービスのライフサイクルに取り入れている国内企業の事例がいくつかヒットします。ようやく情報セキュリティの1分野として確立しつつあるとイベント内で話されていたのですが、この検索結果はそれを裏付ける結果であるように思います。

engineering.mercari.com

tech.plaid.co.jp

実際に「脅威モデリング」をワークショップ形式でやってみた

そんな脅威モデリングを、イベントを通じてではありますが、ワークショップ形式で体験してきました。ワークショップでは、参加者複数人でチームに分かれ、下記に示す機能や要件を持つ架空のシステムに対して要素分解を行ったのち、脅威の分析を行っています。

  • スマートフォンアプリとクラウドサーバー、セキュリティデバイスを連携させるスマートホームセキュリティシステム
  • スマートフォンアプリには「ユーザー認証機能」「セキュリティデバイスの状態表示・制御機能」「イベント履歴の表示機能」の3つが備わっている
  • クラウドサーバーは REST API を外部に提供しているほか、データベースによるデータの保存と管理、セキュリティデバイスとのリアルタイム通信ができる
  • クラウドサーバーへのアクセスにはユーザー認証が必要で、パスワードの暗号化と二要素認証によってセキュアな状態が保たれている
  • クラウドサーバー上のデータベースはバックアップとリカバリが可能となっている
  • スマートフォンアプリとデータベースサーバーの通信はHTTPSによる暗号化をしなければならない
  • そのほかにも多数の機能あり

ワークショップで最初に行ったのは「システムが取り得るデータの流れを、要素分解しながら図式化すること」。文言のみで受領した上記内容を、チームごとにデータフロー図 (DFD) で図に起こします。DFDなんて情報処理技術者試験で触れたぐらいしか経験ないよ...と内心思いながら、以下のような図をチームで作りました。

システムの要素分解と図式化が一通り終わった後は、要素間でデータの信頼度が変わる箇所に信頼境界 (Trust Boundary) と呼ばれる線を引いていきます。上の写真はすでに信頼境界を引いた後のものになりますが「物理か仮想か」「クラウドかスマホか」「認証済みか否か」「パブリックサブネットかプライベートサブネットか」のような観点で検討を進めています。

信頼境界を引き終わったあとは、攻撃者の観点から脅威を洗い出す作業に入ります。今回のワークショップでは「STRIDE」と呼ばれるフレームワークを用いて、システムのどこで下記に示す脅威が発生しうるかを議論しました。

  • Spoofing (スプーフィング) : 攻撃者は他のユーザーになりすまし、不正アクセスできるか
  • Tampering (改ざん) : 攻撃者は不正にデータの変更できるか
  • Repudiation (否認) : 攻撃者は疑わしい行動を否定できるか
  • Information disclosure (情報漏えい) : 攻撃者が機密データなどにアクセスできるか
  • Denial of service (サービス拒否) : 攻撃者がアプリケーションやサービスを停止させられるか
  • Escalation of privilege (特権昇格) : 攻撃者が特権的権限を手にできるか

今回私がいたチームでは、システム全体ではなく「やられたら一番被害が深刻そうなプロセス」に焦点を置き、STRIDEで脅威を洗い出してみました。その結果が以下の図です。

字が読みづらくて大変恐縮ですが、プロセス1個に限定してもSTRIDEのすべてが起こりうることが窺えました。今回のワークショップでは時間に限りがあったためできませんでしたが、本来は洗い出す対象をシステム全体に広げていき、あらゆる脅威を洗い出した後、全体を見ながら脅威ごとに対応方針を決める行程(リスクアセスメント)があります。

「脅威モデリング」をやってみた感想

難しいけど為になるし、何よりワイガヤするのは楽しい!」というのが、今回ワークショップを通じて脅威モデリングをやってみた感想です。システムが架空かどうかに関わらず、抽象度を高くすることで、情報セキュリティの専門家以外であっても関心を寄せ、参加できる土壌が作れるポテンシャルにとても魅力を感じました。最近は、社内でこの手のワークショップ企画を任されることが多いので、取り組んだ内容をネタの引き出しに加え、機会があればアレンジして実践したいと思います。

*1:「企画→設計→実装→テスト→リリース」という一連のソフトウェア開発サイクルの中で、矢印の左側にあたる上流工程からセキュリティを意識しようという考え方

*2:情報セキュリティ・インシデントが起こった後に対応するのではなく、起こる前に積極的な予防をしようという考え方