チームビルディングで「脅威モデリング」ワークショップをやってみた

チームビルディングで「脅威モデリング」ワークショップをやってみた

Clock Icon2025.03.31

こんにちは、こーへいです。

2024年7月にクラウド事業本部(当時はAWS事業本部)コンサルティング部のチームビルディングとして、「脅威モデリング」ワークショップを実施しました。

これはAWSが出している脅威モデリングワークショップ(Threat modeling for builders)をベースに社内用にアレンジしたものを資料として作成しております。

資料

解説

事前準備

貼り付けた画像_2025_03_31_14_14

今回は以下ツールを利用してワークショップを行いました。紙でもいいですが他のチームの状況も見れる状態にするために以下のツールを各チーム毎に用意しました。

  • Cacoo(作図ツール)
    • データフロー図作成用
  • スプレッドシート
    • 脅威や対応策の洗い出し用
  • Slack(コミュニケーションツール)

脅威モデリングとは

貼り付けた画像_2025_03_31_13_12

脅威モデリングとはあまり聞き馴染みがない言葉ですが、「システムに存在する潜在的な脅威と対応策を考え、セキュリティレベルを向上させる取り組みのこと」です。

例えばあなたが建築家だとして家を設計する場合、鍵が全くない家だと泥棒が入って貴重品が取られてしまう(脅威)と考え、対策として鍵をつけよう(対応策)とします。

こういった思考は日常的にもあるはずで、同じ様にシステムに対して脅威や対応策と洗い出すことを脅威モデリングと言います。

メリットは以下の通りです。

貼り付けた画像_2025_03_31_13_15

貼り付けた画像_2025_03_31_13_14

貼り付けた画像_2025_03_31_13_15

脅威モデリングの対象

今回はAWSが用意下架空のシステムを対象に脅威モデリングを実施します(Case Study)。

このシステムはIoTに接続した車両のソリューションシステムとなっています。

全体図の上部分に関しては、基本的にはIoTに接続した車両から走行データを送信し、そのデータを元に車両診断を行うことで、車両が基準値内で運転され、ドライバーが交通規則を遵守していることを継続的に保証するシステムとなっている。

そして全体図の下部分に関しては、車両やドライバー登録の機能を表しています。

今回は範囲が広いので赤字にしている車両登録機能に絞って脅威モデリングを実施します。

詳細な内容はcase-studyをご確認ください。

貼り付けた画像_2025_03_31_13_17

貼り付けた画像_2025_03_31_13_18

演習1:車両登録機能のデータフロー図作成

ここから演習です。まずは架空のシステム構成図をベースにデータフロー図を作成します。

貼り付けた画像_2025_03_31_13_20

これを行うことでシステム内に存在するデータや保管場所の特定、データフローの可視化によるシステム理解の向上に繋げられます。

以下はサンプル図です。

貼り付けた画像_2025_03_31_13_22

チームによって図の起こし方の癖があって楽しかったです。

演習2:メンバーの役割(ペルソナ)を決める

貼り付けた画像_2025_03_31_13_24

各メンバーの役割(各役割は上図に記載)を決めることで、異なる視点での脅威の洗い出しが可能となります。

とはいえ、慣れていない場合はあまり役割に固執しすぎないことが重要です。役割決めは脅威モデリングの質向上が目的で、役割に固執しすぎると脅威モデリングの質を下げてしまう恐れがあります。

特にAppSec専門家は難しいと思います。まずは慣れるところから始めて見ましょう。

演習3:STRIDEチャートを作成する

STRIDEとは、情報システムなどに損害を与えかねないセキュリティ上の要因である「脅威」を6つのカテゴリーに分類したものを言います。

本演習ではデータフロー図で使用した各要素にて脅威の標的または被害者となりうる項目にチェックをつけます。

脅威の発生源ではないことに注意です。例えばユーザーはなりすましの攻撃対象になり得るので○、一方で、改ざんの対象にはなり得ないので×となります。

貼り付けた画像_2025_03_31_13_27

貼り付けた画像_2025_03_31_14_02

貼り付けた画像_2025_03_31_14_02

以下は回答例です。

貼り付けた画像_2025_03_31_15_15

演習4:車両登録機能に対する脅威を特定する

ここまでの演習でシステムに対する脅威を洗い出すための準備は整いました。

基本的に自由に洗い出していただいて構いませんが、進め方がわからない場合は資料にヒントを記載しましたのでご確認ください。

以下は1チームが出してくれた脅威となります。

貼り付けた画像_2025_03_31_14_06

演習5:脅威への対応策を考える

脅威への対応策は以下の4つに分類されますが、今回のワークショップでは既にできる限り多くのリスクをAWSに移行しており、この機能をリリースしない選択肢もない為、演習3では「軽減」や「受け入れる」の選択、もしくは組み合わせて対応するのみとなります。

貼り付けた画像_2025_03_31_14_42

以下は1チームが出してくれた対応策です、今回のワークショップではなるべく数を出してもらう様に伝えています。

貼り付けた画像_2025_03_31_14_07

演習6:振り返り

ワークショップが終われば振り返りです。いろいろな意見があるはずなのでぜひこの時間も確保いただければと思います。

アンケート

実施後頂いたアンケートを一部載せさせていただきます。

企画・運営お疲れ様でした!
なかなか難しい内容でしたが、自分のセキュリティ知識をフル活用できて面白かったです!
ありがとうございました!!!

AWS公式ワークショップのアレンジは楽しめるし、為になるしで、良いアイデアだと思いました。

セキュリティについて、フレームワークに沿ってがっつり議論する機会はなかったので勉強になりました!

終わりに

脅威モデリングのワークショップをベースにカスタマイズしてチームビルディングの教材にするのはなかなか大変だった記憶(半年前なのでちょっと朧げ)ですが、用意する中で理解が深まりまた勉強になりつつ楽しい時間になった等の意見も貰ってやって良かったなと感じています。

是非チームビルディングのテーマに困ったエンジニア用教材の候補となれば幸いです。

参考

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.