前提背景

去年の8月と10月にオンサイトでOWASPの脅威モデリングワークショップに参加してきた。
そこでの知見をここに残す。
脅威モデリングワークを受ける前までは、セキュリティに対して苦手意識を抱いてしまっていた部分があった。
しかし、基本的な脅威の洗い出しをモデリングベースで洗い出し、継続的に脆弱性を明らかにする工程はまるでDDDとそっくりであり、これをUAFの思考プロセスと組み合わせることで、戦略的な脆弱性対策を実現できると確信した。

心構え

ここではアジャイルな脅威分析を前提としている。
以下の①～④に時間をかけ過ぎて⑤の検証の時間を割けないということがないように、
DDDモデリングと同じ考えで、まずは「ここにこんな脅威がありそう」
という仮説をもとに①～④まで迅速に進めて、⑤で検証振り返りした上、
次の①～⑤のイテレーションに落とし込んでいく。

その上で継続的に信頼境界の場所を見つめ直していくことになる。
もしもコンテキスト境界の位置を「セキュリティの観点のみで考えたい」という場合には、
この信頼境界の位置がまさに、サービス境界などになることになる。

ただし、実際にはセキュリティ以外の品質観点も同じくらい重要な場合が多いので、実際に信頼境界の位置とコンテキスト境界の位置が完全に一致することはない。

まずはモデリングするスコープなどの前提条件を明らかにした上で①に取り掛かる。
その際には事前に戦略的DDDモデリングなどによって、
ラフスケッチで構わないので、全体的なコンテキストマップを作成することをオススメする。

①取り組む対象のシステムデータフロー図を描く

まずは上図のようなデータフロー図を描く。
この際にDFD図だけではなく、場合によってはステートマシン図なんかも使うこともある。

②脅威の洗い出し

STRIDE という手法を使ってまずは考えられる脅威を洗い出す。
このSTRIDEというフレームワークに沿って進めることで考慮漏れを防ぐことにもなる。

Spoofing Identity　なりすまし
Tampering with data　改ざん
Repudiation　否認
Information disclosure　情報漏洩
Denial of service　サービス妨害
Elevation of privilege　権限昇格

の頭文字をとってSTRIDE。
このフレームワークにそってまずは考えられる脅威を洗い出す。
コチラ　を参照ください。

③脅威を洗い出した後のリスクの分析

ここではリスクの大きさを評価するフェーズであり、DREADフレームワークを用いて分析する。

Damage potential：潜在的な損害
Reproductivity：再現可能性
Exploitability：攻撃利用可能性
Affected users：影響ユーザー
Discoverability：発見可能性

詳しくはこちらを参照ください。
最近ではBug Barという手法がメインで扱われているようです。

④リスクへの対策考える

リスクポイントが低いものや発生頻度が低い、優先度の低いものは
そもそも受容するなど、
リスクの大きさによって、
・受容
・移転
・低減
・回避(ハイリスクなもの)
の４つの観点で分類し、対策を考える。
コチラを参照ください。

⑤振り返り

①～④を各ビューごとのステークホルダーとともに迅速に行った上で、
⑤での検証振り返りを行い、再度①からまたイテレーション回す。
１回で分析しようとし過ぎずに、①～④まではサクサクと進めて⑤の振り返りでカバー。

次のイテレーションに入った際には、
この検証振り返り結果を踏まえて「そもそもこの脅威が抜けてたよね」といった議論や、
それを踏まえて「このリスク、ポイント高いと思ってたけど違ったね」
といったように、反復するたびに仮説の精度を上げていく。

発見

今回はデータフローを使っての脅威モデリングであったが、この考え方は他にも転用可能であると感じた。

PM観点での脅威

たとえば、プロジェクトマネジメント観点での脅威分析として、

①プロセス上の脅威

プロジェクトの遅延やヒトが欠勤してしまうor辞めてしまう
といったものが列挙できる。

遅延するリスクを抑えるために、チームトポロジーのようなタスクの割当にも設計思想を用いて、意図せず認知負荷が異常にかかるような状況を仕組みで抑止したりする方法は考えられる。

他にはプロジェクト進捗を遅らせるメテオフォールやステークホルダーの強い抵抗といったインパクトのデカい脅威を抑える考えとして、TOC(制約理論)との組み合わせによって、事前に予測できる脅威に対しては最小限に抑えられる。
ただし、それもステークホルダーとの信頼関係のない初期段階とかに関しては、継続的に行わなくてはいけない。

②データの観点での脅威

プロジェクトの成果物に関する重大なデータが、
社員の自宅への仕事の持ち帰りなどによって漏洩してしまうリスクなど。
このあたりは近年出てきたゼロトラストセキュリティの思想が必須になってくると読んでいる。

あとは、社外への重要データ持ち出しは罰則として減給などといった
明確な評価制度の透明化なども重要な活動になってくるであろう。

PdM観点での脅威

自分たちが売り出したプロダクトに対して、競合他社がハックするような戦略を打ち出してくるなど、市場系のリスクが起こりうるかもしれない。

技術系リスクだけでなく、こういった外部環境リスクに対して変化をいち早くキャッチするためには、マーケティングに詳しい人との密な連携以外に何があるのか？は自分ではまだ十分に理解できていない。

ワークフロー上の脅威

これはユーザーが本来意図された使い方の通りに使ってくれない場合や、
途中でサービスが停止してしまうことを想定した脅威分析などが相当する。
障害が起こりにくい仕組みを構築するのか？　
起きてしまった障害から迅速な復旧をするためには、障害が起きているという想定シーンでの復旧活動を事前にある程度設計しておかなくてはいけない。