脅威モデリング

序文

過去15年間、開発ライフサイクルにおけるセキュリティについてエンジニアと話すと、彼らは何度もある質問をしてきた：「セキュリティの専門家たちが規定するすべてのことの中で、私たちが行うべき最も重要な活動は何か？というのも、率直に言って、開発ライフサイクルにおけるセキュリティを保証するような重要な活動は一つもないからだ。なぜなら、率直に言って、開発ライフサイクルにおけるセキュリティを保証するような重要な活動は一つもないからである。バグのない完璧なソフトウェアがないのと同じように、セキュリティに特効薬はないのだ。

しかし、正しい方法で行えば、非常に大きな価値を提供し続ける活動がある。脅威モデリングは、確かに 私たちが推奨する他のセキュリティ活動すべてに取って代わるものではない。脅威モデリングは負担が大きく、終わりがなく、実施する個人やチームのセキュリティ専門知識に依存するという評判がある。しかし、なぜこの活動がすべての開発チームが取り入れるべき価値の高い活動なのか、私の体験を紹介しよう。

私がEMCでセキュリティを率いていた頃、セキュアなソフトウェア開発プログラムを導入して数年のデータがあったため、外部の研究者が当社の製品セキュリティレスポンスセンター（PSRC）に報告した脆弱性を深く掘り下げることにした。この演習の目的は単純で、報告された脆弱性のうち、脅威モデリングによって特定できた可能性のあるものがどれだけあるかを把握することだった。データは圧倒的に、これらの問題の大部分（80％以上）が脅威モデリングで発見されたであろう設計レベルの問題であることを教えてくれた。

次に、侵入テストの結果についても同様の演習を行い、外部テストベンダーのレポートで特定されたことを脅威モデリングで特定できたかどうかを比較した。結果は同じようなものだった。データ主導のアプローチをとることで、私たちは社内の脅威モデリングをより積極的に開発し、実行することに集中するようになった。

このことは、私がオートデスクで現在担っている仕事にも生かされている。脅威モデリングは、単に効果的であるだけでなく、例えば、ソースコード解析ツールを当社のアプリケーションで実行するよりもはるかにノイズが少ないと私は発見した。これは、セキュリティの脆弱性を発見するツールの能力を評価するものではないが、私の開発者体験では、ノイズが少ないということは、開発ライフサイクルにセキュリティ対策を取り入れることに懐疑的でなく、満足度の高いエンジニアが増えることに等しい。

開発者は忙しい。そのため、仕事のやり方を変えたくなかったり、セキュリティチームが望むことを取り入れるためにペースを落としたくなかったりする。IzarとMattは、開発者と一緒に仕事をした長年の体験があり、脅威モデリングをすべての開発者が利用できるようにする方法や、脅威モデリングの結果を効果的な危険性管理に適用する方法について、実践的なヒントをたくさん集めた。マットとイザーが本書で提案していることは、最も重大なセキュリティ上の欠陥をライフサイクルの早い段階で特定することに一歩近づき、開発チームがまだ時間のあるときに、つまりソフトウェアが本番稼動に入る前に、危険性管理の実践に従うことができるようにするものである。

脅威モデリングは、継続的インテグレーションと継続的デプロイのテクニックを採用することが重要なクラウドの世界では場違いなように思えるかもしれない。本書では、継続的なモデリングがどのようなものかを紹介しているので、何時間もホワイトボードに書き込むことなく設計リスクを特定することができる。私はマットとイザーに、継続的モデリングを取り入れたり、自動化を開発したりするための新しいテクニックを考え出すよう挑み続けてきた。オートデスクでは、「すべてを自動化する」というシンプルなマントラに従っている。数年前であれば、脅威モデリングを自動化することは夢物語のように思えただろう。今日、本書で紹介されているいくつかの概念によって、我々はこの夢に近づいているように思える。 ...