セキュリティ脆弱性 SCAP 仕様規格

日々の脆弱性の調査と管理では、通常、脆弱性プラットフォームやチームが異なれば、脆弱性の番号と重大度の定義が異なることがわかります。

たとえば、脆弱性の 6 つの一般的な要素は次のとおりです。

Heartbleed 脆弱性を例に挙げてみましょう。

これらのコンテンツはすべてHeartbleedについて説明しています。異なるプラットフォームには異なる番号とカテゴリがあることがわかります。影響を受けるコンポーネント、レベル、タイトルはすべて異なります。そのため、セキュリティ研究者や脆弱性管理者にとって、それが同じであるかどうかを識別する必要があります。さまざまな人やチームには、次のような矛盾があることがよくあります。

これは、脆弱性に対する知識、理解、標準の違いが原因で、これらの問題が発生します。では、この問題に対処するための統一された基準はあるのでしょうか? そう、SCAPです！

SCAP

今日は主にSCAP1.0バージョンを紹介します。

SCAP にはプロトコルとコンテンツが含まれます。プロトコルとは、SCAP が一連の既存の公的標準で構成されていることを意味します。これらの公的標準は SCAP 要素と呼ばれます。プロトコルは、これらの要素がどのように連携するかを指定します。コンテンツとは、要素記述を使用して生成され、プロトコルの取り決めに従って実際の検査作業に適用されるデータを指します。

SCAP の 6 つの要素:

CVE と CVSS については比較的よく知られていると思いますので、1 つずつ説明します。

CVE

CVE は比較的理解しやすいものです。平たく言えば、脆弱性を統一的に収集し、番号を付けたものです。もちろん、これは一般的なコンポーネントの脆弱性に対するものです。これが、セキュリティ担当者が履歴書に CVE を何回乗り越えたかを書いているのをよく見かける理由です。番号は、その番号に対応する共通コンポーネントの脆弱性がその時点で彼によって 0DAY で発見されたことを意味し、これは彼の独立した 0DAY 発見能力の象徴です; もちろん、CVE は脆弱性の影響と重大度を反映していません。 CVE 番号だけでは何も表示されませんが、非常に弱い脆弱性が CVE 番号に適用される可能性があります。

CVSS

CVSS はスコアリングシステムであり、基本的な表現方法は右のような直接スコア 5.0 またはそれに類似したものです。

CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N/RL:O/CR:L

このベクターの発現に関して、ここでの AV、AC などが何を意味するかについては、以下を読み続けて大まかなアイデアを得ることができます。

CVSS スコアには 3 つの指標グループがあります。一般に、脆弱性自体の重大度を見るときは、主に基本的な指標に注目します。この指標は、脆弱性自体のいくつかの点からさらに計算され、時間指標グループも考慮される場合があります。たとえば、時間の経過とともに、最初は脆弱性を悪用する方法がなかったが、後から脆弱性が現れた場合、脆弱性の悪用はまったく異なり、ハザード指数はおそらく直線的に上昇するはずです。 Eternal Blue は、脆弱性が発生した当初は Exp を伴うものであり、その使用方法を知っている人は限られていましたが、オンライン上のさまざまなエクスプロイト記事や MSF プラグインの出現により、世界中の人々が利用できるようになりました。さらに、環境指標は主に、さまざまな環境に対する脆弱性の影響を指します。

先ほども言いましたが、上記のAVとは何でしょうか？実際、それはこれらの指標項目です。詳細は下の図で見ることができます。誰もが理解しやすいように、PPT で中国語に翻訳されています。ここでの H と L は高値と低値を表している可能性があります。詳細については、を参照してください。公式 Web サイトの説明 https: //www.first .org/cvss/specation-document。

スコア計算の話に戻りますが、スコアはどのように計算するのでしょうか? 実は計算式があり、基本的な指標群を例に挙げてみましょう。

脆弱性の各指標がどのような状況に属するかを判断します。たとえば、攻撃ベクトルには、ネットワーク、隣接ネットワーク、ローカル、および物理が含まれます。これらは、脆弱性攻撃を開始するいくつかの方法を指します。計算に使用される対応する因子スコアは、0.85、0.62、0.55 です。 , 0.2. 一般に、ネットワーク経由で直接攻撃できる脆弱性は悪用するのが最も便利であるため、スコアが最も高くなります。他のいくつかの指標についても同様です。

例として「phpMyAdmin に反映される XSS の脆弱性 (CVE-2013-1937)」という脆弱性を見てみましょう。

次に、式を適用して計算します。

ISCBase = 1 - [(1−ImpactConf) × (1−ImpactInteg) × (1−ImpactAvail)] = 1 - [(1−0.22) × (1−0.22) × (1−0)] = 0.3916

ISC =
Scope Unchanged 6.42 × ISCBase
Scope Changed 7.52 × [ISCBase−0.029] − 3.25 × [ISCBase−0.02]15
=7.52 × [0.3916−0.029] − 3.25 × [0.3916−0.02]15 = 2.72675084384

Exploitability
= 8.22 × AttackVector × AttackComplexity × PrivilegeRequired × UserInteraction
= 8.22 × 0.85 × 0.77 × 0.85 × 0.62 = 2.8352547300000004

If (ISC <= 0) 0 else,
Scope Unchanged Round up (Minimum [(Impact + Exploitability), 10])
Scope Changed Round up (Minimum [1.08 × (Impact + Exploitability), 10])
= Round up (Minimum [1.08 × (2.72675084384 + 2.8352547300000004), 10])
= Round up (Minimum [6.006966019747201, 10])
= 6.1

この脆弱性の最終的な基本スコアは 6.1 でした。

この計算は面倒だと思いますか？実際には、それほど複雑である必要はなく、公式ウェブサイトにはオンライン計算ツールが用意されており、それを選択するだけで自動的に計算されます。

これがCVSSです。

CPE

CPE は一般的なプラットフォームの列挙であり、脆弱性を説明する場合、多くの場合、その脆弱性が影響するコンポーネントとバージョンを説明する必要があり、その後 CPE を使用できます。

CPE には、WFN、URI、FS の 3 つの形式があり、対応する形式は次のとおりです。

CPE:2.3:类型:厂商:产品:版本:更新版本:发行版本:界面语言:软件发行版本:目标软件:目标硬件:其他

CPE にも複数のバージョンがあるため、以前の 2.3 は使用する CPE のバージョンを指します。バージョン 2.2 では、sw_edition、target_sw、target_hw などのフィールドは存在しません。具体的な表現方法については、CPE の左側を参照してください。上図サンプル。

もちろん、CPE は、脆弱性の影響を受けるコンポーネントと対応するバージョンを記述するだけでなく、脆弱性が存在するかどうかを直接照合するためにも使用できます。特定の環境のコンポーネントのバージョンを検出するには、CPE を使用して記述し、比較します。影響を受ける CPE のバージョンを照合することで、環境がこの脆弱性の影響を受けるかどうかを直接説明できます。このシナリオでは、CPE は対応する照合方法を使用します。詳細については、上の図を参照してください。コードに実装されているため、非常にシンプルです。一般に、既製のモジュールがあります。たとえば、Python には、CPE とも呼ばれる既製のサードパーティパッケージがあり、関連するマッチングおよび書式設定メソッドが含まれており、簡単に使用できます。

CCE

CCE について話しましょう。実際、CCE は理解しやすいです。ベースライン構成の CVE 番号として理解できます。CVE は一般的なコンポーネントの脆弱性を表し、CCE はベースライン構成を表します。

たとえば、図に示すように:

CCE-27868-9
定義: Apache のサービスアカウントのパスワードの最大有効期間設定は、適切に構成する必要があります。パラメータ: 日数。技術メカニズム: ローカルまたはグループポリシーによって定義されます。

CCE-27868-9 では、Apache サービスアカウントの最大有効期限の要件が説明されており、適切な値を使用する必要があります。

オーバル

検査項目や脆弱性などの技術的な詳細を定義するための記述言語であるOVALの話の続きです。これを理解するのは難しいように思えますが、平たく言えば、特定の脆弱性の存在を、対応する環境で段階的に検出する方法を示しており、そのような番号から検索できるライブラリも備えていると理解できます。は上图oval:org.mitre.oval:def:24241XML 形式です。例として心臓の出血を考えてみましょう。

これはその一部で、Ubuntu 12.04 では、システムに libssl 1.0.0 などの dpkg パッケージがあり、そのバージョンがそれより小さい場合、Heartbleed 脆弱性があることを意味します0:1.0.1-4ubuntu5.12。

OVAL は、統一された標準を使用して特定の脆弱性の検出詳細を記述しており、OVAL はコミュニティからも提供されるため、セキュリティ担当者やセキュリティツールは OVAL に基づいて関連する脆弱性を実際に検出できます。

XCCDF

最後にお話しする必要があるのは、XCCDF についてです。

XCCDF は OVAL に似ていますが、XCCDF は、情報交換、ドキュメント生成、組織的および状況に応じた調整、自動整合性テスト、およびコンプライアンススコアリングをサポートするように設計されており、さまざまな基本的な構成チェックテクノロジとの対話をサポートできます。推奨されるデフォルトの検査テクノロジーは MITRE の OVAL です。実際の SCAP アプリケーションでは、XCCDF と OVAL がペアで使用されることがよくあります。OVAL が XCCDF のサブセットとして使用できることがわかります。

OVAL に加えて、実際には XCCDF ドキュメントで CPE を確認できます。これも XML 形式のファイルです。

6つの要素を振り返ると、インターネットから画像を拝借して表現しましたが、実際には、それぞれの関係と働きはおおよそ次のとおりです。

SCAPツール

そうは言っても、SCAP の使用に役立つ関連ツールはありますか? 例えば、XCCDFに基づいて検査結果をどのように検出して出力するのか。より有名なものには OpenSCAP があります。

これはおそらく SCAP の簡単な紹介ですが、詳細については、公式 Web サイトのドキュメントといくつかの適用事例を参照してください。

実際、SCAP の主な機能は標準を統一することです。この場合、セキュリティ研究者やセキュリティツールを使用せずに、これらの標準を直接適用して、関連する脆弱性の調査、学習、使用、検出などを行うことができます。理解の違いによる差異は生じないが、記述や定義が異なるなどの問題が生じる。一般に、優れたセキュリティ製品は、独自の標準セットを持っている場合でも、一般に一部の SCAP と互換性があり、その中で CVE が最も広く使用されています。もちろん、SCAP の使用中に標準についての異なる理解があった場合、それによっていくつかの相違が生じる可能性があります。たとえば、CVSS を計算するプロセスでは、脆弱性のさまざまな指標の決定に関する公式の説明と説明がありますが、脆弱性に対する理解が異なると設定結果も異なり、最終的な計算値も異なる可能性がありますが、これは避けられないことですが、SCAP では可能な限り統一された標準を提供するよう努めています。

注: SCAP バージョン 1.2 で新たに追加されました

CCSS Common Configuration Scoring System (CVSS に似ています) (ただし、CVSS は脆弱性用であり、CVE に関連付けられています。CCSS は構成用であり、CCE に関連付けられています) OCIL Open Checklist Interactive Language (XCDDF に似ています)

参考文献

脆弱性の命名

脆弱性の命名に関しては、SCAP 仕様には含まれていない一連の命名仕様を以前に設計しましたが、全体的な目的は、脆弱性に名前を付けることで、どのような脆弱性であるかを大まかに把握することです。続く：

文法

脆弱性ライブラリ内の脆弱性の名前には、主に、脆弱性を生成するコンポーネント (つまり、脆弱性の影響を受けるコンポーネント) の名前、つまり、脆弱性の影響を受けるバージョン、脆弱性が発生する場所、脆弱性の種類、およびオプションが含まれます。命名規則は次のとおりです。

漏洞影响组件名称+漏洞影响版本+漏洞产生位置+(向量)+漏洞类型

脆弱性の影響を受けるコンポーネント名: 脆弱性の影響を受けるコンポーネント名は、主に脆弱性を生成する特定のコンポーネントの名前を指します。コンポーネントには、さまざまな Web アプリケーション、特定のプラグイン、特定のシステム、特定の汎用モジュールなどが含まれます。これらはすべてコンポーネントと呼ぶことができます。
脆弱性の影響を受けるバージョン: 脆弱性の影響を受けるバージョンとは、脆弱性の影響を受けるコンポーネントに対応するバージョン番号を指します。ここでのバージョン番号は、単一バージョン (V1.0 など) または範囲 (V1.0&<2.0 など) にすることができます。 )、または設定は最小値 (>V1.0 など) または最大値 (\<V2.0 など) です。
脆弱性の場所: 脆弱性の場所は、脆弱性の原因となる特定の問題を指します。問題が存在するファイルの場所 (/admin/admin.php など)、または特定の一般的な関数名またはクラス名 (_LoadBMP 関数など)、またはどちらも人の組み合わせ。
ベクター: ベクターはベクターを指します。これはオプションであり、脆弱性の入力ポイントを指します (たとえば、SQL インジェクション脆弱性のベクターはパラメーター ID です)。
脆弱性の種類: 脆弱性の種類とは、一般的な脆弱性の種類、つまり、脆弱性に対応する一般的な分類における脆弱性分類の名前を指します。

原則として

最初は、脆弱性名から脆弱性の基本情報を理解できます。
脆弱性名の重複はできる限り避ける
長くて意味のない脆弱性名は避ける

例

ThinkSAAS 2.0.1 thinksaas.php ローカルファイルには脆弱性が含まれています
ImLib BMP イメージ _LoadBMP 関数のサービス拒否の脆弱性
UFIDA U8 system/Server/CmxGetLoginType.php ファイルの appid パラメータ SQL インジェクションの脆弱性

脆弱性評価

脆弱性評価の問題に関しては、多くの人は脆弱性レベルを表すために「高、中、低」または 1 ～ 10 という用語を使用することに慣れています。私はまた、Microsoft の DREAD リスクモデルに基づいてセットを設計しました。これもまた、リスクモデルの一部ではありません。 SCAP. 以下も参照できます: 脆弱性の合計リスクレベルは 10 レベルに分かれており、1 ～ 4 が低リスク、5 ～ 7 が中リスク、8 ～ 10 が高リスクです。

計算式

危险=发生的概率×潜在损失

採点項目の定義

潜在的な損失: 欠陥が悪用された場合、どれくらいの損失が発生しますか?
再現性: 攻撃を再現するのはどのくらい難しいですか?
悪用可能性: 攻撃を開始するのはどのくらい難しいですか?
影響を受けるユーザー: 大まかな割合で、何人のユーザーが影響を受けますか?
発見可能性: 欠陥は見つけやすいか?