はじめまして、品質改善推進ユニットの根本です。 ユニットではプロダクトや業務プロセスの品質を継続的にモニタリングし、改善計画の作成を支援していくパートナーシッププログラムという取り組みが始動しました。
詳しくは下記の記事をご覧ください。
モニタリングのスコープにはセキュリティも含まれます。今回は、このセキュリティのモニタリングに、スレットモデリングを取り入れる試みについて、ご紹介したいと思います。
課題
モニタリングの方法としては、システムを直接診断するもの、セキュリティにかかわる業務プロセスを診断するものが考えられます。例えば、システムを診断するものとしては、Webアプリケーションやプラットフォームの脆弱性診断 などがあげられ、業務プロセスを診断するものとしては、脆弱性への対応業務プロセスを整備状況や運用状況の面から評価するものなどがあげられます。
これらは、第三者もしくはツールが診断を実施し開発・運用チーム側にレポートすることが一般的です。そのためレポートされる開発・運用チーム側は受け身の姿勢になりがち、という状況が発生します。
第三者による客観的な診断結果は必須なものですが、最もシステムについて詳しいのは開発・運用チームですから、もったいない状況ともいえます。開発・運用チームがもつシステムそして業務プロセスに関する情報が診断の精度を上げることは間違いありません。
この課題について、スレットモデリングが解決の一助になるかもしれません。プロダクト開発・運用のステークホルダーが参加し、自らセキュリティ面の脅威（スレット）を洗い出していくところに効果を期待できるからです。
スレットモデリング
スレットモデリングは、システムの設計段階で用いられる脅威の洗い出し・分析・評価の手法ですが、すでに運用に入ったシステムについても実施する価値があるといえます。大きなシステムの場合、どこに対して優先的にセキュリティ対策を実施していくかなど、限られたリソースを振り分ける際の判断材料になるからです。
スレットモデリングについて詳しく知りたい方は下記をご覧ください。
今回の試みでは二つのアプローチをとりました。
- STRIDEモデルの活用
- 公開されているスレットモデル情報の活用
１．STRIDEモデルの活用
まず、DFD（データフロー図）の作成を通して、重要なデータの流れについて参加者間で情報を共有します。つぎに、STRIDEモデルとよばれる脅威を洗い出すための観点を通してデータの流れを追い、思いつく懸念点を出し合っていきます。この洗い出し作業を脅威ブレストと呼んで、DFD上に付箋紙を張る方法で進めました。
Microsoft のSTRIDE定義
このアプローチでは多くの懸念点を出し合うことができました。一方、実施上の課題も見えてきました。
当初は抽象度の高いDFDからはじめ、段階を踏んで具体性を高め、それに合わせて洗い出す脅威の具体性も高めていく予定でした。しかし、システムと常に向かい合う開発・運用チームはすでに具体的な懸念点を持っており、脅威ブレストよりも既知の懸念点を直接リスト化する方が効率的でした。
このように、すでに具体的な懸念点が認識されている場合、必然的にそちらにフォーカスすることになるためデメリットが生じました。新たな脅威を見つけ出すことが手薄になる点です。STRIDEで脅威を洗い出していくには、練度を上げることが必要と感じました。
また、脅威ブレストにしろ、既知の懸念点のリスト化にしろ、そこで出てきたものが本当に脅威であるかは、さらに踏み込んだ調査が必要となりました。短い開発サイクルで多くの機能を実装・改修する開発・運用チームにとっては、この活動のためのリソース確保が最大の課題といえます。
２．公開されているスレットモデル情報の活用
特定の技術については、すでにスレットモデルが検討され公開されているものがあります。今回の試みでは、OAuth2.0 に関する下記の文書を活用することができました。
文書の扱いには作法があり、少し文書自体について説明をします。
この文書は、現在インターネットドラフトという状態で、まだ作業が進行中（work in progress）の文書です。2016年11月から作成され始め2021年4月にはドラフトの18版がでました。文書内に、この18版の有効期限は2021年10月と記されています。
また、BCP（Best Current Practice）という種類の文書に属し、OAuth2.0実装におけるセキュリティ面のベストプラクティスを検討している文書ということになります。
文書の第２章には実装時のセキュリティに関する推奨事項がまとめられています。内容理解にはOAuth2.0に関する前提知識が必要とされますが、OAuth2.0については書籍の出版もあり、インターネット上からも多くの情報を得ることができるので、それらを参照しながら理解を進めていくことができます。
第３章ではどのような攻撃者を想定する必要があるのか確認することができ、第４章では具体的な脅威および対策について知ることができます。
第２章の推奨事項や第4章の対策事項は「MUST（NOT）」や「SHOULD」などの形で表現され、対策の必要性について強弱が分かるようになっています。これらの表現が対策優先度の判断において拠りどころとなり、たいへん便利といえます。各表現の定義は、RFC2119、RFC8174で確認することができます。
今回の試みでは、モニタリング対象のシステムに当てはまる脅威を文書から探し出し、先の「MUST（NOT）」や「SHOULD」を考慮しながら確認項目をリストアップすることができました。
このような文書を活用できるのは、脅威の考慮漏れを防ぐという面でも大変有効だと感じられます。また、具体的な対策まで知ることができるので脅威を洗い出した後の対策検討も楽になります。
一方、このアプローチにおいても課題がないわけではありません。先ほど「システムに当てはまる脅威」と書きましたが、OAuth2.0の実装の詳細を知るために、DFDよりも詳しいシーケンス図を必要としました。開発チームからは詳細な図を提供いただき確認項目のリストアップが可能になりました。
まとめ
ブレストを通してざっくばらんに懸念事項を出していくアプローチ、特定の技術について公開された文書から核心部を確認していくアプローチ、両方にメリットがあることは確かだと感じました。
そして、スレットモデリングという手法にトライしながら、脅威があるかもしれない事項に気づいたとき、気づいた脅威に特化してその有無を検証する作業が必要になりそうだと感じました。
スレットモデリングの方法として、STRIDEとともに紹介されることのあるPASTAという方法が有効ではないかと考えています。
今回は、セキュリティのモニタリングにスレットモデリングを取り入れる試みについて、大まかに紹介させていただきました。
この試みをすすめるなかで、ご紹介できるような失敗談、成功事例などが出てくると思います。それらを、また別の機会にご紹介できればと思います。
LIFULLでは共に成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。
