脆弱性のリスクスコアを計算または推定するためにどのリスクレーティング方法、モデル、評価、または方法論が使用されているか(= /// =)(たとえば、 OWASPトップ1 )そして、それらのうちどれがウェブの脆弱性に最も適していますか?
私は次の3つを認識しています。
他のモデルまたは同等の目的の方法論が存在しますか(または現在開発中)?
MC(モンテカルロ法)、ベイジアン統計、またはその他の適切な変数処理、モデルに拘束された公式のリスク分析に基づくかどうかにかかわらず、情報リスクの要因分析(FAIR)、または任意のバリューアットリスク(VaR)モデル-これらのいずれかが最高になると、より効率的なリスク計算になります。
ISC2のメンバー(CISSPなど)の場合は、PivotPoint Analytics(以前はCyberPoint Intlでしたが、現在はその一部)でCyVaRをチェックアウトできます- http://go.pivotpointra.com/lp -isc2-member-benefit
CyVaRは RiskLens と同様に、VaRモデルで情報リスクに関与する方法です。次の3冊の本にも情報がたくさんあります(効率が向上しています)。
本の1つは、今日の3つの中で最も実用的なものですが、すぐに変更される可能性があります。本では、Vulnerabilityと呼ばれる単一の変数として扱われる脆弱性がよく見られます。これは、FAIRのバージョンの可能性、FAIR標準は損失イベント頻度と呼んでいます。
損失イベント頻度(LEF)について知っておく必要があるのは、LEFは「頻度」だけでなく「頻度の頻度」も指示することです。ジェネリックなlikelihood変数は、イベントが今日、今週、今月、今年、この10年間発生する可能性が高い場合、質問者をぶら下げたままにします。またはその他の不特定の日付。正確なイベントがいくつ発生するかは記載されていません。 LEFはこれをすべて変更します。これにより、意思決定者は、損失イベントが発生する頻度と回数(例:年間)を理解することができます。
この単一の答えであなたを納得させることはおそらくないでしょうが、Vulnerability変数は、緩和策を介して制御するのが困難です(Open FAIR標準ではこれらを脆弱性コントロール)は、基になるDifficulty変数に影響します。脅威コミュニティの(TCom)Threat Capability(TCap)変数がDifficulty変数の場合、十分に高度なTCapを持つすべてのTComにより、脆弱性が90%(多くの場合100%)を超えるため、LEF方程式のこの側でほぼ確実に損失イベントが発生します。
これを状況に即して説明させてください。 Dukes(別名CozyBear別名APT 29))が、Webアプリのエントリポイントが対象の米国ベースの金融サービス会社に対してWeb Shellを付与すると決定したとしましょう。デュークス(つまり、ハンドラー)は、東ヨーロッパのいくつかの機密資産をオンラインカーディングフォーラムに参加していると信じさせました。資産の1つは、いくつかのwebappsecの経験があり、遅くとも完全にひび割れたwebappsecスキャナー、Acunetixを渡されていますバージョン。アセットは、ハンドラーが俳優に提供した金融サービスのWebサイトのリストに対して実行されます。ハンドラーは、以前の機密資産チームを使用して、誇りに思っているリストを作成するために必要な偵察を行いました。
約3週間後、多くのwebappsec脆弱性がWebshellのアップロードに使用される可能性があると資産は確信していますが、それらの一部はSQLインジェクションであり、PGSQLやDB2などの非標準のRDBMSバックエンドがあります。おそらくこれらの1つにも、Webアプリファイアウォール(WAF)が配置されています。東ヨーロッパのアセットには、WAFをバイパスしたり、これらのベクトルを介してWebシェルをロードしたりするためのTCapがありません。ただし、フォーラム(私たちのセカンダリTCom)を介してチェーンを上り、Dukes(プライマリTCom)に戻った後、DukesはWAFをバイパスするために必要な才能を持っています(たとえば、 sqlmapの修正バージョン)と、PGSQLおよびDB2バックエンドに対してWebシェルを構築する方法の理解。したがって、Dukes TComのTCapは、Difficultyのすべてをバイパスするのに十分な高さです。
この場合、ターゲットWebサーバーはBeyondTrust PowerBrokerまたはwinbindを介して少なくとも1つのMicrosoftドメインにも接続されており、Dukesはgetent(1)ユーティリティを使用してユーザーをダンプし、SMBRelayおよびジャスバグ。ドメインには、Microsoft Forestへの信頼関係があり、最終的にDukes Forest Administratorのアクセス権が付与されるため、SAP ERPおよびSAPなどのサービスをホストしているドメインを含むすべてのドメインに読み書き可能です。 Oracle Hyperion、HMIS、Essbase、およびJDEに加えて、S/4 HANA。これらのサービスは、財務レコード、全社的な金融サービスに加えて、従業員、パートナー、請負業者、および顧客のレコードを含むデータベースもホストします。知的財産。この時点で、Dukesは永続性レイヤーをインストールし、平均5年(通常3〜9年)のシステム管理者として機能できるようにします。この時点で、VaRは会社全体のトップライン成長です-すべての売上高、すべての収益創出ビジネス。
シナリオなどを重要と評価していますか?妥協評価レポートで太字または赤を使用していますか? FAIRによると、VaRは米ドルなどの金額で表示する必要があります。
CVSSは、ほとんどすべての脆弱性レポートで使用されるリスク評価モデルになる傾向があります。
MicrosoftのSDLで言及されている1つのモデルは [〜#〜] dread [〜#〜] と呼ばれます
これは主に、脅威のモデリング段階でソフトウェア設計の潜在的なリスクを測定するために使用されますが、脆弱性にも適応できます。 ここ はDREADのもう1つの便利なリンクです。
構成管理システムの作業に関する私の経験では、これらは、企業があなたが言及したものとは別に、一般的に使用する指標です。
次の方法で脅威の評価を行うことができます。
ツールの例: Nessus脆弱性スキャナー および Qualys Webアプリケーションスキャナー
[〜#〜] cwss [〜#〜] もあります。ドキュメントは CVSSとの違い についても説明しています:
- CVSSは、脆弱性がすでに発見および検証されていることを前提としています。 CWSSは、脆弱性が証明される前のプロセスの早い段階で適用できます。
- CVSSスコアリングでは不完全な情報は考慮されませんが、CWSSスコアリングには不完全な情報のサポートが組み込まれています。
- CVSSv2スコアリングは、物理システムへの影響に大きく偏っています。 CWSSには、弱点を含むアプリケーションを支持する小さなバイアスがあります。
また、CWSSはCVSSよりも解釈の余地が少なく、より一貫したスコアリングが得られると聞きました。
CVSSは非常に人気があります。 AcunetixやIBM App Scanなど、多くの組織がCVSSを使用しています。 WebアプリスキャナーでもあるWeb InspectとBurp Suiteは、研究者の経験を利用して、発見に重大度を割り当てます。 CVSS v3はCVSS v2よりもはるかに優れており、Webアプリケーションの脆弱性に適しています。
パーティーには少し遅れましたが、この pdf で他のいくつかのリスクモデリングフレームワークに出くわしたので、念のためここに追加します。それらのいくつかは便利に思えますが、いつものようにYMMVです。