脅威モデリングを自動化する時代へと突入する?

Threat Modeling in the Age of Automation

2021/07/16 SecurityBoulevard — サイバー・セキュリティの脅威は急速に増加しており、アプリケーションを構築する企業は、将来の攻撃に耐えるためのコアとなる脅威モデルを含めて、予防原則に基づくセキュリティ対策を検討するようになってきた。しかし、Security Compass の最近の調査によると、ソフトウェア開発の初期段階 (要件の収集/設計) において、脅威モデルを取り入れている企業はわずか 25% だった。さらに、開発したアプリケーションの 90% 以上において、脅威モデルを取り入れていると回答した企業は 10% 未満であり、脅威モデルの自動化や統合において半数以上の企業が課題を抱えていることが分かった。

Security Compass の CEO である Rohit Sethi は、「従来の脅威モデルでは時間がかかり過ぎ、完成までに数日を要することも少なくない。また、脅威のリスト/対策/図式化は、現代のソフトウェア開発のペースを前提にすると、すぐに陳腐化してしまう」と述べている。さらに、STRIDE と呼ばれる脅威の判定方法は、エラーを発生しやすく、進化する攻撃を見逃してしまう可能性があるとも述べている。加えて、この方式で考慮されていないものとして、ソフトウェアの設計で考慮すべきデータ保護法などの、コンプライアンスに関する負担も増えているという。

さらに重要なことは、優れた脅威モデルを構築するためには、セキュリティに関する専門知識が必要だが、それは大半の企業に不足しているものだ。したがって、多くの組織は、脅威モデルの作成を少数の重要なアプリケーションに絞り込むことになる。結果として、脅威モデルを作成しても、安全な設計に役立てることができず、単にコンプライアンス演習としてのモデル化になるか、その取り組みを完全に放棄してしまうことになる。企業が脅威モデリングの取り組みの目標を本当に達成したいのであれば、アプリケーション開発の迅速化というビジネス上のニーズと、リスク管理の目標とのバランスを取る必要がある。

脅威モデリングの自動化

Rohit Sethi は、「このような取り組みを、効果的かつ大規模に行うためには、自動化が必要だ。脅威のモデリングの大部分は自動化できる。たとえば、ソフトウェア設計において知られている、脅威のリストを定義することは、必ずしも手作業による分析を必要としない。MITRE の CWE (Common Weakness Enumeration) に記載されている、特定の技術/機能/プログラミング言語が、セキュリティ上の既知の弱点に影響を与えることが知られている。つまり、ソフトウェアの技術的属性を、潜在的な脅威に結びつけ、また、対策に結びつける作業を、自動化することは可能だ」と述べ、自動化にコストをかける必要はないと付け加えている。

堅牢な商用ツールは無料ではないが、より多くのセキュリティ専門家を雇って手作業で行うよりも、TCO (total cost of ownership) を大幅に引き下げられる。業界で認められたベスト・プラクティスに従わなかった結果として、当局や訴訟に対してコストとリソースを浪費するのではなく、セキュリティ上の欠陥に対して貴重なエンジニアリング・サイクルを費やさせる。Sethi は、ソフトウェア開発におけるコンプライアンス遵守という、増大している負担に対処するためには、脅威モデルのプロセスとツールを活用する必要があると述べ、既存の GRC (Governance / Risk / Compliance) プログラムは、ソフトウェア開発に最適化されていないと説明している。

また、米国国防総省 (DoD) の成功例が参考になるとも述べている。最近のことだが、国防総省は継続的な運用権限 ATO (Authority To Operate) を導入しましたが、それは民間企業にとっても、Secure-by-Design プロセスを統合して DevSecOps に結びつけるモデルとなるだろう。Sethi は、「また、フレームワーク/コンテナ/マイクロサービスや、その他のインフラ・コンポーネントに適切なコントロールをシームレスに組み込むことで、ソフトウェア開発者からセキュリティに関する懸念を取り除くことを、模索する傾向も見られる」と述べている。それは、どのコンポーネントに、どのようなコントロールが実装されているかを追跡し、重大なギャップがないことを確認することを意味するものであり、将来的における脅威モデルの重要な利点となるだろう。

より成熟し、より優れた、状況認識力

Netenrich の CISO である Chris Morales は、脅威モデルは常に重要であるが、実践している組織は少ないと述べている。なぜなら、攻撃がどのように機能し、攻撃対象とどのように関連しているのかを理解する必要があり、それを推進する知識や時間を持つ個人が少ないからだろう。Chris Morales は、ユーザー/資産/接続といった企業内の攻撃対象全体が、脅威のモデル化に取り込まれるようになったと指摘している。彼は、脅威のモデル化が時間のかかるプロセスであることを認めた上で、「問題が発生する前に、実際の脅威に対して組織が、どのように対処するかを評価することで、リスク管理のための定量的な方法を提供する。我々は、組織のリソースを標的にしているワイルドな脅威に対する、現在のセキュリティ態勢を理解するために、ライトウェイトなモデリングを可能にする、運用モデルに移行する必要がある」と述べている。そのためには、可能な限り自動化して、SecOps や DevOps チームだけでなく、組織のすべての部門に状況を認識してもらうための、継続的なアウトプットを可能にする必要がある。

普段は漫然と眺めるだけの CWE ですが、脅威モデリングの自動化という話になるなら、注目すべきフレームワークになるでしょうね。文中に、個々の CWE に関連するプログラム言語の話があったので、ちょっとだけ調べてみたら、その記述が本当にありました。自分を含めた多くの人々が、CWE のタイトルしか見ていないというのが、セキュリティの世界の現状だと思います。それじゃぁ、Miter さんに失礼というものです。ゴメンナサイ。

別の記事でもコメントしましたがー、アプリケーションやシステムを「作る人」のセキュリティ意識の向上が一番のポイントだと思います。意識がないと、素敵なCWEが目の前にあっても全く活用できないですからね。。。

%d bloggers like this: