Lite Threat Modeling を使用した迅速な安全な開発

Lite Threat Modeling を使用した迅速な安全な開発

Lite 脅威モデリング PlatoBlockchain データ インテリジェンスを使用して安全な開発を迅速に進めます。垂直検索。あい。

多忙なソフトウェア企業では常に新しい開発が行われています。 しかし、安全な開発も行われているのでしょうか?

ライト スレット モデリング (LTM) と呼ばれるプロセスでは、利害関係者が安全な開発に関与し、セキュリティが組み込まれており、ボルトで固定されていないことを確認します。 LTM とは何ですか? 従来の脅威モデリングとの違いは何ですか?

ライト脅威モデリング アプローチ

LTM は、システムまたはアプリケーションの潜在的なセキュリティの脅威と脆弱性を特定、評価、軽減するための合理化されたアプローチです。 の簡易版です 従来の脅威モデリング、これには通常、セキュリティ リスクのより包括的かつ詳細な分析が含まれます。

LTM では、ペンテストのようにシステムやアプリが壊れるかどうかを確認するために手動でピンをシステムやアプリに突き刺すことはありません。 むしろ、アプリケーションに「理論上の穴」を開け、考えられる攻撃手段と脆弱性を明らかにします。

以下に、尋ねることを検討すべきいくつかの質問を示します。

  • 誰が私たちのシステムを攻撃したいと思うでしょうか?
  • システムのどのコンポーネントが攻撃される可能性があり、どのように攻撃される可能性がありますか?
  • 誰かが侵入した場合に起こりうる最悪の事態は何ですか?
  • これは当社にどのような悪影響を及ぼしますか? 私たちの顧客に?

LTM はいつ実行されますか? 

新しい機能がリリースされたとき、セキュリティ コントロールが変更されたとき、または既存のシステム アーキテクチャやインフラストラクチャに変更が加えられたときはいつでも、LTM を実行することをお勧めします。

理想的には、LTM が実行されます After 設計段階と   実装。 結局のところ、脆弱性を本番環境にリリースする前に修正する方がはるかに簡単です。 組織全体で LTM を拡張するには、明確で一貫したプロセスと基準を確立する必要があります。 これには、共通の一連の脅威カテゴリを定義し、脅威と脆弱性の共通の原因を特定し、リスクを評価および軽減するための標準的な手順を開発することが含まれます。

組織で LTM を実行する方法 

組織内で LTM の実行を開始するには、まず社内のセキュリティ チームに LTM の会話を主導してもらいます。 エンジニアリング チームがプロセスに慣れてくると、独自の脅威モデルの実行を開始できます。

組織全体で LTM を拡張するには、明確で一貫したプロセスと基準を確立する必要があります。 これには、共通の一連の脅威カテゴリを定義し、脅威と脆弱性の共通の原因を特定し、リスクを評価および軽減するための標準的な手順を開発することが含まれます。

LTM で避けるべきよくある間違い

セキュリティ担当者は、脅威のモデル化が得意です。彼らはしばしば最悪の事態を想定し、想像力に富み、エッジ ケースを考え出します。 しかし、これらの性質により、次のような LTM の罠に陥ることもあります。

  • 外れ値にこだわりすぎ。 これは、LTM 演習中に会話の焦点が最も現実的な脅威から外れ値に逸れたときに発生します。 これを解決するには、エコシステムを完全に理解する必要があります。 セキュリティ情報およびイベント管理 (SIEM) およびその他のセキュリティ監視システムからの情報を使用します。 たとえば、アプリケーション プログラミング インターフェイス (API) エンドポイントを攻撃する攻撃が 10,000 件ある場合、攻撃者がそれを狙っていることがわかります。 これは、LTM が注目すべきことでもあります。
  • テクニカルになりすぎる。 多くの場合、理論上の脆弱性が発見されると、技術者は「問題解決モード」に飛び込みます。 彼らは結局、脆弱性が組織に与える影響について話す代わりに、問題を「解決」し、技術的な実装について話すことになります。 LTM 演習中にこれが発生していることに気付いた場合は、会話を元に戻すようにしてください。まだ実装について話すつもりはないことをチームに伝えてください。 を通して話す リスクと影響 最初。
  • ツールだけでリスクを処理できると仮定します。 多くの場合、開発者はツールがすべての問題を発見することを期待しています。 結局、現実には、脅威モデルは特定の脆弱性を見つけることを意図したものではありません。 むしろ、システムの全体的なリスクをアーキテクチャ レベルで検討することを目的としています。 実際、安全でない設計は OWASP の最新のものの XNUMX つでした。 トップ 10 の Web アプリケーション セキュリティ リスク. アーキテクチャのセキュリティの問題は修正が最も難しいため、アーキテクチャ レベルの脅威モデルが必要です。
  • 潜在的な脅威と脆弱性を見落とします。 脅威のモデル化は、XNUMX 回限りの作業ではありません。 潜在的な脅威と脆弱性を定期的に再評価して、絶え間なく変化する攻撃ベクトルと攻撃者の一歩先を行くことが重要です。
  • 高レベルの実装戦略をレビューしていません。 潜在的な脅威と脆弱性が特定されたら、それらを軽減または排除するための効果的な対策を実装することが重要です。 これには、入力の検証、アクセス制御、暗号化などの技術的な制御の実装と、従業員のトレーニングや管理ポリシーなどの非技術的な制御の実装が含まれる場合があります。

まとめ

LTM は、潜在的なセキュリティの脅威と脆弱性を特定、評価、軽減するための合理化されたアプローチです。 非常に開発者にやさしく、安全なコードを移動できます 早期に脅威モデリングを行う ソフトウェア開発ライフサイクル (SDLC) で。 さらに良いことに、LTM は、ラボに頼って脅威のモデリングを実行するのではなく、ソフトウェア開発者やアーキテクト自身が行うことができます。

LTM を一貫性のある効果的な方法で開発および実装することにより、組織は最も重大なセキュリティ リスクを迅速かつ効果的に特定して対処できると同時に、一般的な落とし穴や間違いを回避できます。

タイムスタンプ:

より多くの 暗い読書