この記事は、元々興味をもって調べていた「脅威モデリング」について、皆さんの講演を聞いたりTMC Tokyo × ZANSIN（以下、長いのでtmctokyoと記載）を体験した中で「つまりこういうものか」という一定の腹落ちを得たのでメモ書きするもの。
普段ブログで書いているHow to系の話と違い、個人の感想レベルだし、今そう思っているだけでまた考えが変わるかもしれない。
けど、tmctokyoという素晴らしいイベントを通じて、自分が感じ考えたことを今の断面として書いておきたい。
TMC Tokyo × ZANSINとは
一言でいえば脅威モデリングとハードニングを連続で味わえる貴重な機会。
ただし、今回は表題の話に重点を置きたいので詳細説明は割愛する。
興味がある方は他の参加者の記事を見て頂きたい。
結局、脅威モデリングとは何なのか
以下、自分がモヤモヤしていたポイントに対して感じたこと。
自分メモなので「そもそも脅威モデリングの流れは…」みたいな基礎解説は割愛する。
何の図を使えばいいのか
基本的に「DFD」と言われる。シーケンス図でもいいよ、とも言われるが活用例は見たことがない。
自分の中では、①DFD作るの大変では？②DFDはどの範囲で作るの？③システム構成図じゃダメなの？がモヤモヤポイントだった。
今の自分の考えは
①大変じゃない程度に5～10分で作るものでいい
②割と狭い範囲で良い
③システム構成図とDFD両方いる。目的により片方でよい場合もある
①と②はほぼ同じ話で、仮に組織全体とか巨大システムに対して詳細粒度で洗い出そうとすると、それだけで数か月が流れ、一千万円近いコンサル費用を要し、誰も理解できない複雑な図が生まれ、図を産み落としたところで力尽きる未来が見える。
そうならないように、広い範囲に適用する場合は極限まで抽象度を高め、少し細かく見たい場合は特定の機能や業務など範囲を小分けにするしかない。図を作ることが目的ではないので使える図を作る。
だから「5～10分で書いてください」で書けるレベルがちょうど良いのだと思う。
以下の記事でも「If you spend more than 5 minutes on this, then its probably too long.」と書かれていて気になっていたが、実際にやってみてそう感じた。
③について。
システム構成図は、インフラレベルの脅威（OSなどの脆弱性、不要なネットワークの穴を狙った攻撃など）を予測するために有用。
DFDは、アプリケーションの機能レベルの脅威（セッション管理の不備、不十分な入力値検証などを狙った攻撃など）を予測するために有用。
今回tmctokyoで取り組んだZANSINでは、小規模なゲームシステムを対象にシステムの乗っ取り（主にインフラ）とゲームのチート行為（主にアプリ機能）両方の脅威に備える必要があった。この場合は、両方の図を用意したほうが網羅的に脅威の洗い出しができる。
逆に、「組織全体の環境に対する分析」みたいなデカい話の場合は、システム構成図に頼ったほうが向いていると思う。
ちなみにtmctokyoでは約20チームがそれぞれ図を書いたが、システム構成図ベースで書いたチームが多かった印象。
私のチームは、先に脅威の方が色々思いついたので「あの脅威を表すならこの絵がいる」の流れでDFD（主）とシステム構成図（副）の両方を書いた。午後のZANSHINで概ね脅威を予測できていたことが確認できたので、2つ書いて良かったのだろうと思う。
どう脅威を洗い出すのか
基本的に「STRIDEモデル」の活用が挙げられる。他にもPASTAとか色んなモデルがあるようだが詳しくないし活用例は見たことがない。
自分の中では、STRIDEの何がそんなにありがたいの？がモヤモヤポイントだった。
だって、STRIDEは6種類の脅威の頭文字なだけで具体性はないし、細かい攻撃手法を知る人がいないと意味のあるモデリングにならないじゃん、と。
今の自分の考えは「確かに具体性はないけどそれで良い」
理由は最後のセクションで触れる。
セキュリティに詳しくない人は、脅威というものを考える入口としてSTRIDEを使えば良い。その結果がどれだけ具体性があるかは慣れとメンバ次第。考え始めるのが大事。
セキュリティに詳しい人は、システムの情報を知った瞬間に一気に何十もの脅威が頭に浮かぶ。それをSTRIDEにコツコツ当てはめる意味はあまりないので、まずは経験ベースでざっと書き出して、後で忘れていた観点がないかをSTRIDEでチェックする使い方が良い気がした。
どう優先付けするのか
基本的に「DREAD」「アタックツリーモデル」の活用が挙げられる。
自分の中では、考え方は有用だけど本当にそこまでやる？がモヤモヤポイントだった。
今の自分の考えは「説明可能性と再現性をどこまで重視するか次第」
単発かつ短時間の検討の場合、正直そこまでやっている時間はない。
しかし、組織の戦略立案に繋がるような話の場合、数年後にその根拠を求められることはよくある。
それに備えるなら上記の方法を使ってMECEに定量的に検討経緯を残しておく。
tmctokyoの場合は単発かつ短時間だったので「境界防御に直結するか」「守りたいテーマに対して一撃必殺でやられる脅威か」くらいの観点で各脅威に１群、2群、その他的な色分けをした。
例えば管理画面が外部に露出しているとか、SQLインジェクション（DB消される）とかは1群。チートでAPIを不正利用されるのは2群（あるいはそれ以下）みたいな感じ。
脅威モデリングとは何なのか
先に結論的な考えを書く。
脅威モデリングとは、システム担当がセキュリティに向き合うための準備体操ではないか。
そしてその体操は「ベースラインアプローチ」と「リスクベースアプローチ」を連結するために役立つのではないか。
私は、これまで上記２つのアプローチを分けて考えていた。
前者はチェックリストに沿うこと。後者は各システム固有のリスクを分析すること。
前者は誰でもできる簡単なこと。後者はセキュリティ担当が関与すべき難しいこと。
脅威モデリングは後者に含まれる意識でいた。
そして、脅威モデリングはとても大変な作業だから、それをやるのは超重要な一部のシステムに絞り、その他大多数のシステムはベースラインアプローチでカバーせざるを得ないのでは？と考えていた。
それが脅威モデリングナイト#3で話した内容。
言い換えれば「チェックリスト or 脅威モデリング」の構図で考えていたが、そうではない気がした。
そもそもベースラインアプローチとリスクベースアプローチはグラデーションのように繋がっている関係であり、ベースラインアプローチを有効に・効率的に機能させるためにもリスクベースアプローチや脅威モデリングが必要なのではないか。
私のようなセキュリティ担当は、当然自社のセキュリティチェックリストの中身を熟知している。
脅威モデリングで行きつく対策は大体チェックリストに書いてあることを知っている。
だから「チェックリスト通りに作ればいいのに」と簡単に言ってしまう。
でも、各システムの担当はそうではない中「チェックリストに沿ってください」と言われても、大量の要件を前にマトモに向き合う気にはなれない。
仮に向き合ったとしても、各要件をシステムのどこに実装すべきか？を結び付けるのがまた難しい。
脅威モデリングは、精度の差はあれどシステム担当者が自分の頭で脅威と対策を考えることに意味がある。
それを一度でも考えれば、後にチェックリストと向き合う場合でも大量に並んだ項目を自分の目でメリハリつけて見れるし腹落ち感もある。
また、対策の実装を漏らしたらマズい箇所も分かるので、単なるチェックリストの遵守ではなく意味をもった実装に繋げられる。
少し理想論すぎるかもしれないが、機能要件やスケジュールに追われまくっている多忙なシステム担当者が「セキュリティと向き合う」ためには心と頭の準備体操がいるわけで、そこに脅威モデリングは役立つし、そのくらいから始めていくのが良いのではと思った。
tmctokyoの場合。
このイベントは、通常の「システム開発における脅威モデリング」ではなく「インシデント対応（ハードニング）のための脅威モデリング」という関係が少し特殊。準備体操後にいきなり戦争が始まる。
しかし、その中でも前半の脅威モデリングは後半のハードニング（ZANSIN）のためにうまく機能できると感じる場面があった。
脅威モデリングの中で優先付けした各脅威・対策の付箋に対し、ハードニングの中で「どの作業が済んだか」を書き込んでいけば、インシデント対応状況の可視化ツールになる。
加えて、メンバ全員が「他に１群の優先度の中でやってないタスクはどれ？」と自分で次の手を考えて動くための道しるべにもなる。
実際にはハンドリング役はやはり必要だしハードニングは技術力が無いと話にならないので「脅威モデリングさえできれば対策が万全」という話ではないが、脅威モデリングという準備体操をしていたから効率の良い順序で対策が出来たのでは？と思った。
（私たちのチームは上位入賞はしなかったが、技術的に本質的な対策をしっかりやれていたチームとして評価していただけていたことが後に分かった）
（なお、私は技術的な面では何の貢献もしていないことはｷﾘｯと明記しておく）
そんなわけで脅威モデリングは成果物そのものよりも「考えること」にまずは主眼をおいて、社内でも広めていきたいな～と思った。
最後に。
運営の皆さま、スポンサーの皆さま、素晴らしい体験の機会をありがとうございました。
お世辞抜きで今年一番参加して良かったイベントでした。
これまでの記事一覧はこちら
