約1年前に、TMC Tokyo × ZANSINというイベントに参加して感じたことを書いた。
今回は、そこから1年経って考えが加わったこと、変わらなかったことを続編として書き留める。
前回同様、個人の感想であり正解を提供するものではないことは予めお断りです。
この1年間で何をしたか
社内向けに脅威モデリングワークショップを2回開催。脅威モデリング関連のイベントに5回参加。
社内向けワークショップは、開発部向けの教育の一環でやってみよう！と企画したもの。
その時の内容や気づきは以下。
しかしその後、社内向けの活動がストップしているのは反省点。
理由は別件で忙しいから。というのもあるが、開発部からの「具体的な脅威を洗い出せない」の悩みに答えかねていたのも正直ある。
イベント参加はほとんどTMC Tokyo（旧称：脅威モデリングナイト）。他社や海外の取り組み事例を聞いたり、レッドな人たちによるAI × 脅威モデリングな話を聞いたり。そして直近はSTRIDEモデルを開発されたローレン・コンフェルダーさんのお話を聞いた。
今年のTMC Tokyoは、以前に比べて抽象度高めのテーマに思考を巡らせたり皆で議論する場に変わった印象（小笠さんぽい）。
考えが加わったこと
脅威モデリングで洗い出す脅威の抽象度は高くて良いのかも。という考え。
いや、同じことは前回のブログにも書いた。加わったのは「具体化を目指さないパターンもある…というか脅威モデリングは元々詳細なリスク評価のための手法ではないのでは？」と思ったこと。
前回のブログを書いた時点では、抽象度の高いところからスタートして徐々に具体化を目指すイメージを持っていた。多分、それはそれで間違いではない。脅威モデリングの目的によっては具体性や網羅性が必要な時もあるだろう。実際に、3月にTMC Tokyoで話してくれたDonavanさんはSTRIDE-LMとMITRE ATT&CKを併用して脅威を洗い出していると述べていて、比較的細かい粒度で取り組んでいる印象を受けた。目的次第。
それはそれとして、抽象度が高いまま完了する脅威モデリングもアリなのかもしれない。
ローレンさんの話の初っ端から印象的な言葉があった。（うろ覚え）
「モデルとは、複雑なものを抽象化して把握することだ」
「私達は人間でさえモデルで捉えている。どんなに相手のことを知っても具体的に相手が何を考えているかは分からず『こんな人』として捉えているだけだ」
はい、実は私はずっと脅威モデリングの「モデリング」って何？って思ってました。
モデル＝抽象化だとすると、脅威モデリングはそりゃ抽象的な世界で論じることだよね。
複雑で壮大なものをあえて抽象化してシンプルにして、それについて色んな立場の参加者が「こんなことが起きると嫌だよね」を話し合う。
XSSによりCookieを盗まれたら…セッションIDを推測されたら…みたいないきなり細かい手法レベルではなく（それもあって良いが）、ここで認証済のはずのユーザが別の人になりすまされたら？それが困るなら特に注目して対策考えなきゃね。みたいな要注意ポイントを洗い出す感じでも良いのかなと。
そう考えると、書籍などで脅威モデリングが開発の早期段階のアクティビティとして位置づけられている理由も、STRIDEモデルがざっくりした分類だったのも、脅威モデリングマニフェストに「誰でも実行できる」と書いてあるのも、納得いく気がする。
元々細かいことを話したいわけではなかったのか、と。
一口に脆弱性といってもサービスレベルの問題、ロジックレベルの問題、コードレベルの問題と色々ある中、脅威モデリングの抽象度は、まずはサービスやロジックレベルの要注意ポイントを発見するイメージで取り組んだ方がやりやすいのかもなと思った。
補足すると、開発プロセス全体にわたって抽象度が高いままで良いと言いたいのではない。具体化はやっぱり必要だけど、それは脅威モデリングとは別の段階や手法でやれば良いのだろうと。例えばAIに聞いてみるとか。診断するとか。
あと、ローレンさんが「最近はプライバシーの侵害、自動運転での違法行為、生命の安全に関わることなど脅威が増えてきたからSTRIDEで表現しきれないものもある」と言っていたのも注目したい。
抽象的ではあっても新しい脅威の種類は見落としてはならず、STRIDEに縛られるべきではない。
2025/11/17 追記：ローレンさんから当日のスライドが公開されました。感謝感謝。
考えが変わらなかったこと
脅威モデリングとセキュリティチェックリストの関係。
脅威モデリングに不慣れな私たちは、それをやるよりは全部チェックリストに書き出して、それを守れば安心じゃん！という発想になりがち。そうしてチェックリストを魔改造しがち。（←主犯）
だけど、開発者はそんなに大量の項目を渡されても、どれが自分のシステムに関係する/しないのか？具体的にシステムのどの部分にどの項目が関わるのか？が分からないので、結果的に「多分やってるはず」程度の回答になり、ナンチャッテ統制になる。
「全部チェックリストに書いたから高品質」は幻想に過ぎず、自分のシステムに関連する脅威や対策を紐づけるためにも脅威モデリングという思考の時間は必要なのだろうと思う。そしてチェックリストはできるだけ参考書にしたほうがよい。
そんな考えは前回のブログにも書いたことであり、ローレンさん小笠さんとの会話でも「やっぱりそうか」と思えた。
まとめ（まとまらない）
色々書いたけどこれも一つの説に過ぎない。
まだまだ答えは定まらず、引き続き色んな話を聞いてもやもやと考え続ける。それは好きだけど、自分は実務担当でもあるので、なんとかして組織にフィットする形や運用についても答えを見出さなければなければならない。
なんとなく、次の理解のステップに必要なのは、社内ワークショップでやったような架空の簡易なWebアプリケーションではなく実際の業務アプリを題材にやることと、脅威モデリング単体ではなく前後（特に後）の開発プロセスも含めて品質向上の流れを体感すること（その全体における脅威モデリングの立ち位置を探ること）な気がした。
