web-dev-qa-db-ja.com

脆弱性スコアリングシステム

当社は、eコマースに使用するウェブアプリを開発しています。最終的に弊社またはお客様から報告されたセキュリティ関連の問題について、より正式なスコアリングシステムを確立したいと考えています。目的は、パッチ開発に優先順位を付けると同時に、クライアントに重大度を伝えることです。

これまでに Common Vulnerability Scoring System を評価しました。シンプルで正確なようです（環境指標をスキップします）。スコアリング用のオンライン計算機があります。さらに、独自の計算機を開発するのも簡単です。

私の質問は- [〜＃〜] cvss [〜＃〜] の最も人気のある選択肢は何ですか？ [〜＃〜] cvss [〜＃〜] と比較した長所と短所は何ですか？簡単に方法を見つけられるように、またはさらにいくつかのシステムを真剣に評価する必要があるように、比較のチートシートのようなものはありますか？

web-applicationcvss
6
Lachezar Balev

Tony CoxとJeff Lowderが [〜＃〜] cvss [〜＃〜] についていくつかの優れた解説を提供しています（実際にSIRAには多くの良い議論が含まれています）。彼らの目標はあなたの目標より少し広いですが、参照された記事はCVSSに関する解説のインデックスを提供していると思います。 @Metahumanの投稿は、CVSSを補完できることを指摘しています。

国務省の iPostシステム は、CVSSのスコアリングが重要でないリスクの価値を推定していることを発見しました。私が正しく思い出せば、深刻なものを強調するために単に値を3乗しただけです。州のiPostは、DHS [〜＃〜] caesars [〜＃〜] -のモデルです（国務省検査官によると、欠陥のあるモデルです）。しかし、どちらも目標よりも建築的です。

CVSSは欠陥のある標準です-私はそれを改訂/改革するための積極的な努力があることを知っています。評価にはかなりの主観があります-現時点では参照を見つけることができませんが、誰かがいくつかの専門家に脆弱性に関する同じ情報を提供し、CVSSプロセスを使用してテストを実行しましたが、非常に異なる答えを導き出しました。しかし、それは標準です。独自の方法論を作成することなく、参照標準を探しているプロジェクトなどを始めるのに最適な場所です。 CVSS（およびCWE）を開始点として使用し、@ Colin Cassidyが「魔法の数学」と呼ぶものを実行できます。

CVSSはシステム中心です。それはアーキテクチャのセキュリティ機能を無視し、おそらくWeb /クラウドが配信ベクトルである脆弱性を過小評価します。 [〜＃〜] owasp [〜＃〜] と Veris を調べて、理論的なモデルではなく、実際のエクスプロイトに関する統計情報を確認します。

私はおそらく環境指標を無視しないでしょう。実際、中期的には、CVSSのコンポーネントを使用して、ニーズにより密接に適合する独自の脆弱性スコアをロールバックし始めます。

5
Mark C. Wallace

5つの要素をスコアリングするDREADに基づくスコアリングシステムを使用します

  • 損傷、脆弱性はどれほど悪いか
  • 信頼性、脆弱性は常に機能しますか、それとも時々機能しますか
  • 悪用可能性、脆弱性を悪用するためにどれだけの努力が必要か
  • 影響を受けるユーザー、影響を受ける人数
  • 発見可能性、この脆弱性を発見するのはどれほど簡単か

5のうち、1と5のスコアが製品とこれらのカテゴリに対して何を意味するかを大まかに定義しました。次に、魔法の計算を行って、脆弱性の重大度と優先度を導き出します。詳細は David LeBlancの投稿 を参照してください。この方法にはいくつかの利点があることがわかりました。1つ目は、製品のスコアの意味を示し、2つ目は、管理者が驚くほど簡単に理解できることです。

4
Colin Cassidy

要件に基づいて、Common Weakness Enumeration（CWE）を確認することをお勧めします。 http://cwe.mitre.org/about/index.html 。

これは、ソフトウェアのセキュリティの脆弱性を説明するためのコミュニティ支援ソリューションであり、脆弱性修正活動のベースラインとしても機能します。

3
Metahuman

CVSSは脆弱性を評価するための合理的なシステムであり、技術的影響の可能性を判断するための優れたフレームワークですが、それは話の一部にすぎません。ビジネスにとって重要なのは、脆弱性が悪用された場合、またはシステムがダウンした場合にビジネスが失う可能性がある金額です。マイナーなサービス拒否の状態を作成するために使用される可能性のある脆弱性が導入される可能性がある場合、それにより、例えば、偽の注文を作成するために使用される可能性がある脆弱性よりも損失が少なくなります。

経営陣は通貨単位で考えるので、リスクを金額損失で表す必要があります。開発には会社の費用がかかります。損失の可能性がバグを修正するための開発コストよりも大きくない限り、彼らはバグを修正しません。

2
GdD

情報セキュリティ管理とリスク管理の目的で定量的リスク分析データを使用する場合、2つのスコアを実行することを好みます。

1）FTAまたはフォールトツリー分析。これはボトムアップアプローチを使用して行われます
2）FMEAまたは障害モードと影響分析。トップダウンアプローチを使用して完了

0
atdre