脅威モデリングに入門したい（続き
こんにちは。貴島(@jnkykn)です。最近は、ずっと技術ブランディングについて考えています。企業や製品のブランディングとは方向性が異なることを、しっかり説明できるようにならなくてはと思っています。こちらは、今取り組んでいることが解決できたら、記事にしたいのでがんばります。さて、先週は、脅威モデリングに入門したくて、「STRIDE」について調べました。今週は、Microsoftの「Uncover Security Design Flaws Using The STRIDE Approach」で解説されている例をもとに、脅威モデリングの練習をしたいと思います。
STRIDEの例題で練習
先週は、脅威モデリングとはどういうものか？STRIDEとは何か？について調べました。今週は、STRIDEの進め方をサンプルシステムを使った例題をもとに学習します。
サンプルシステムのデータフロー図
「Uncover Security Design Flaws Using The STRIDE Approach」に例示されているサンプルシステムは、営業部隊から会計ファイルを収集、データベースサーバーで売上データを集計、毎週レポートを作成するというものです。
前提
会計ファイルは機密性が高いため、入力する営業担当者の識別が必要
営業担当者は認証と承認が必要
データの転送中、保管中の漏洩からの保護が必要
処理アプリは、SQLインジェクションやバッファオーバーフローなどの入力時の攻撃から保護が必要
サーバーは、少なくとも週に1回、計算処理の実行が必要
サンプルシステムのデータフロー図を、自分でも描いてみました。
各営業担当者が会計アプリにデータを入力し、会計データとして集積され、サーバーに転送されます。サーバー側では、外部システムのデータと会計データをもとに集計と分析をした結果を分析DBに集積します。
システムのイメージができますし、これでOKなのでは？と思っていたのですが、分析DBをもとにレポートが生成されるため、これでは完全ではないようです。
魔法のデータ ソースやシンクには注意が必要とあり、クライアント側も整理して、データを読み書きするプロセスを明確にします。
いきなりこの完成形が描ける気がしないのですが、同記事にデータフロー図が適切かどうか？のチェックポイントが挙げられているので、拠り所にしたいと思います。
魔法のデータソースやデータシンクに注意する（データは何もないところで、作成されない）
各データの読み書きのユーザーが表現されているか？
データを読み書きするプロセスがあること確認する
モデリング時に、単一の信頼境界内の類似の要素を1つの要素にまとめる
信頼境界の両端の詳細モデリングに注意する
コンテキストDFDと、より詳細を表すブレークアウトダイヤグラム推奨
データフローとデータストアの分析
サンプルシステムのデータフロー図の解説を読みながら、メモを追記したのが、下図です。
営業担当者の入力データ→集計と分析
入力されたデータ転送中の改ざんの可能性
営業担当者の認証で、なりすましの可能性
転送中のデータ漏洩
サービス拒否
外部システムのデータ→集計と分析
入力されたデータ転送中の改ざんの可能性
システム削除等によるサービス拒否
分析処理→分析DB
信頼境界内にある場合は、低リスク
信頼境界外にある場合は、情報漏洩やサービズ拒否の可能性
データフロー図に、メモを追加していって、漏れがないか確認するのも良いかもしれないと思いました。また、分析データベースが、クラウドサービスやリモート接続された外部サーバーにある場合、データベースを信頼境界外に置いた図に修正しなければならないなど、考慮すべき要素がわかりました。また、機能の詳細よりも、システム全体を俯瞰し、主要な機能について考えるようにするというのも意識したいところです。一度データフロー図を描いてOKと思うのは危険で、図が適切かどうか慎重に見直すようにしたいと思います。（データフロー図が肝って感じですね👀）
まとめ
脅威モデリングは、攻撃者の目線で脅威を洗い出す必要があるというところが難しいと感じました。いきなり攻撃者の目線を持つのは難しいかもしれませんが、攻撃手法のリストをもとにチェックすることはできそうです。また、情報セキュリティの専門家に限らず、プロセスやデータについて様々な観点から脅威を洗い出せると良さそうな印象を持ちました。