web-dev-qa-db-ja.com

アプリケーションのセキュリティ債務を計算する方法は？

アプリケーションセキュリティ債務 は技術債務といくつかの類似点がありますが、セキュリティ債務の負荷が高すぎて完済する必要があるかどうかを判断するときに考慮する必要がある違いはほとんどありません。私たちの銀行アプリケーションでの保証債務の計算方法を知りたいのですが？

web-applicationappsecbanksrisk-managementrisk-analysis
11
Filipon

現時点では、技術的負債のサイズ（在庫）を計算する標準化された方法はありません。私はグラスゴー大学の博士研究員とMIT=この問題に対処するためのフレームワークの作成を開始しました。私たちはMITのシステム理論的プロセス分析をセキュリティ（ STPA-Sec ）および Vulnerability Design として知られる海軍艦艇アーキテクチャの概念。この手法は組織およびサブプロセスを分析することを目的としていますが、分析のターゲットとして単一のアプリケーションにも適しています。

以下は開発およびテスト中です。それでもコンセプトは役に立ちます。

システム理論脆弱性工学

私のチームにとって「アプリケーションセキュリティ債務」を計算することは、「システム理論の脆弱性エンジニアリング」のもう1つの形です。これは、自動化されたスキャナーとパッチおよび構成で対処できる典型的な脆弱性管理とは異なります。代わりに、問題の「システム」（この場合はアプリケーション）を、他のシステムに接続するときに、人、プロセス、およびテクノロジーの完全なコンテキストで調べます。このシステム理論の観点から、次に、脆弱性と弱点（近未来の脆弱性）がどこにあるかを判断します。

これらの脆弱性は、次の範囲にわたる可能性があります。

  • 緩和策の背後に隠されたSQLi（ベアおよびエクスポーズされたSQLiの脆弱性はissueであり、debtではありません）
  • パッチされていないサブシステム
  • トリガーして完了するために人間の介入が必要な手動パッチプロセス
  • 監査の欠如

これらすべては、「セキュリティ債務」または「システムの脆弱性」を表しています。

このアプローチは脅威とは関係ありませんが、脆弱性は脅威を理解することで定義できます。これは脅威モデリングプロセスではありません（前のセクションを参照）。

ステップ1：脆弱性分析（ハイパーコンデンスフォーム）

  1. セキュリティ問題を定義します（あなたは何を心配していますか？）
  2. 安全でない制御の例types（プログラムロジック、システムメンテナンス、保証など）
  3. 安全でない制御タイプ（プロセス、テクノロジー、リソース、知識、文化など）の特定原因
  4. それらの原因が現在存在するかどうかを確認します（定常状態または断続的）

システムの現在の脆弱性を体系的に分析することになります。

しかし、今でもdoについて何かする必要があるかどうかを判断する必要があります。

ステップ2：応答制御分析（ハイパーコンデンスフォーム）

  1. 特定された各脆弱性に対応する応答/回復制御を決定します（安全でないイベントを検出して対応できますか？）
  2. 脆弱性が悪用したり、脆弱性が原因で発生したインシデントを十分に含むことができない対応/回復コントロールを決定
  3. 十分な応答/回復制御が不十分な制御につながる可能性がある現在の脆弱性に苦しんでいるかどうかを判断します。

緩和策が不十分なセキュリティ脆弱性のリストが作成されます。これはあなたの借金です。

このプロセスから生じるすべての項目が技術的であるとは限らないことに注意してください（実際、最初のケーススタディから、技術的である項目はほとんどありません）。 SQLiの問題は、実際にはコード品質プロセスではなく、機能重視の開発文化の結果であるコードレビュープロセスの弱点であることに気付くかもしれません。この場合、借金は文化的なものです。

ステップ3：リスク調整

ここで、1）さまざまな方法（人、プロセス、またはテクノロジ）で脆弱性を低減することと、2）応答制御を改善することの間のトレードオフの設計を開始しますシステムの目標をサポートできるようにするため。

リスク軽減プロセスと同様に、軽減コストを予想損失よりも低く抑える必要があり、システムの目標をサポートするためにすべてを完了する必要があります。

脆弱性モデリングと脅威モデリング

システム理論と脆弱性に重点を置いたアプローチを採用することにより、このプロセスは費用効果が高く、問題の影響ではなく根本的な原因を対象とする改善策を促進することがわかりました。また、脆弱性を減らすために削除する必要がある領域を特定します（減算プロセス）。

脅威に焦点を当てたアプローチは、反応的で、費用がかかり、技術的で、付加的である傾向があります（新しい脅威があり、さらに多くのものが必要です！）。これは、それを減らすのではなく、より多くの借金を作成する効果があります。

6
schroeder

私が聞いた最良のアドバイスは、セキュリティ債務の結果として発生する可能性のあるさまざまなタイプのイベントすべてのリストを把握することです。次に、これらの各イベントのコストを見積もります。次に、これらのイベントが毎年発生する可能性を把握します。最終的な数式は次のようになります。

Probability(event type 1) * Cost(event type 1) + 
Probability(event type 2) * Cost(event type 2) + 
... +
Probability(event type N) * Cost(event type N)

たとえば、セキュリティデビットによって悪用される可能性のある2つの問題があると判断したとします。SQLインジェクション+ CSRFです。 （私は数学を簡単にするために数字を作りました）：

  • 年間5回のSQLインジェクション攻撃が成功すると予想されます。それぞれの攻撃には10万ドルの回復コストがかかります。
  • 1回あたり25,000ドルの回復コストで、10件のCSRF攻撃が成功すると予想されます

問題の年の保証債務の推定コストは次のようになります。

（5 * $ 100,000）+（10 * $ 25,000）= $ 750,000

6
Dan Landberg