performing-asset-criticality-scoring-for-vulns

脆弱性に対する資産の重要度スコアリング

概要

資産の重要度スコアリングでは、各 IT 資産にビジネスへの影響度を割り当て、組織にとって最もリスクの高いシステムに脆弱性修 remediation の取り組みを集中させます。重要度の情報がなければ、テストサーバー上の CVSS 9.0 の脆弱性も、決済処理データベース上の同じ脆弱性も、同じ緊急度で扱われます。このスキルでは、データの機密性、ビジネス機能への依存度、規制対象範囲、ネットワークへの公開状況、復旧可能性を組み込んだ多要素スコアリングモデルを構築し、脆弱性修 remediation の SLA を直接変更する 1～5 の重要度階層を作成します。

使用する場面

• 脆弱性に対する資産の重要度スコアリングを実施するセキュリティ評価を行うとき
• 関連するセキュリティイベントに対するインシデント対応手順に従うとき
• 定期的なセキュリティテストや監査活動を実施するとき
• 実地テストを通じてセキュリティ制御を検証するとき

前提条件

• 構成管理データベース（CMDB）または資産インベントリ
• ビジネスインパクト分析（BIA）データ
• データ分類ポリシー
• ネットワークアーキテクチャのドキュメント
• 事業部門の責任者からの意見

主要な概念

資産の重要度スコアリングモデル

要素	重み	スコア範囲	説明
ビジネス機能への影響	25%	1-5	サポートするビジネスプロセスの重要度
データの機密性	25%	1-5	処理・保存するデータの種類と機密性
規制対象範囲	15%	1-5	規制要件（PCI、HIPAA、SOX）
ネットワークへの公開状況	15%	1-5	インターネット公開か、内部限定か
復旧可能性	10%	1-5	RTO/RPO 要件、DR 対応能力
ユーザー数	10%	1-5	影響を受けるユーザー・顧客の数

重要度階層の定義

階層	スコア範囲	ラベル	SLA 変更率	例
1	4.5-5.0	最重要資産	SLA を -50%	ドメインコントローラー、決済システム、ERP
2	3.5-4.4	高価値	SLA を -25%	メールサーバー、人事システム、CI/CD
3	2.5-3.4	標準	SLA の基準値	内部アプリ、ファイルサーバー
4	1.5-2.4	影響小	SLA を +25%	テスト環境、プリンター
5	1.0-1.4	最小限	SLA を +50%	廃止予定の資産、隔離されたラボ

データ機密性のスコアリング

スコア	分類	例
5	制限付き／機密	PII、PHI、決済カードデータ、企業秘密
4	機密	財務報告書、人事記録、ソースコード
3	社内	社内文書、ポリシー、プロジェクトファイル
2	一部公開	マーケティング資料、プレスリリース（草稿）
1	公開	公開済みコンテンツ、公開 API

ワークフロー

ステップ 1：スコアリング基準を定義する

class AssetCriticalityScorer:
    """Multi-factor asset criticality scoring engine."""

    WEIGHTS = {
        "business_function": 0.25,
        "data_sensitivity": 0.25,
        "regulatory_scope": 0.15,
        "network_exposure": 0.15,
        "recoverability": 0.10,
        "user_population": 0.10,
    }

    TIER_THRESHOLDS = [
        (4.5, 1, "Crown Jewels", -0.50),
        (3.5, 2, "High Value", -0.25),
        (2.5, 3, "Standard", 0.00),
        (1.5, 4, "Low Impact", 0.25),
        (1.0, 5, "Minimal", 0.50),
    ]

    def score_asset(self, asset):
        """Calculate criticality score for an asset."""
        weighted_score = sum(
            asset.get(factor, 3) * weight
            for factor, weight in self.WEIGHTS.items()
        )
        score = round(weighted_score, 2)

        for threshold, tier, label, sla_mod in self.TIER_THRESHOLDS:
            if score >= threshold:
                return {
                    "score": score,
                    "tier": tier,
                    "label": label,
                    "sla_modifier": sla_mod,
                }
        return {"score": score, "tier": 5, "label": "Minimal", "sla_modifier": 0.50}

    def adjust_vuln_sla(self, base_sla_days, asset_tier_data):
        """Adjust vulnerability SLA based on asset criticality."""
        modifier = asset_tier_data["sla_modifier"]
        adjusted = int(base_sla_days * (1 + modifier))
        return max(1, adjusted)  # Minimum 1 day SLA

ステップ 2：脆弱性の優先順位付けと統合する

def apply_criticality_to_vulns(vulns_df, asset_scores):
    """Enrich vulnerability data with asset criticality context."""
    for idx, vuln in vulns_df.iterrows():
        asset_id = vuln.get("asset_id", "")
        asset_data = asset_scores.get(asset_id, {"tier": 3, "sla_modifier": 0})

        vulns_df.at[idx, "asset_tier"] = asset_data["tier"]
        vulns_df.at[idx, "asset_label"] = asset_data.get("label", "Standard")

        base_sla = get_base_sla(vuln["severity"])
        adjusted_sla = int(base_sla * (1 + asset_data["sla_modifier"]))
        vulns_df.at[idx, "adjusted_sla_days"] = max(1, adjusted_sla)

    return vulns_df

ベストプラクティス

1. 重要度スコアリングにはビジネス関係者を参加させます。IT 部門だけではビジネスへの影響を評価できません。
2. 少なくとも四半期ごと、またはシステムの役割が変わったときに、重要度スコアを見直して更新します。
3. 可能であれば、CMDB タグやデータ分類ラベルを使用してスコアリングを自動化します。
4. リスクに応じた修 remediation のため、脆弱性 SLA に重要度階層を適用します。
5. 実際のインシデント影響データと照合してスコアリングを検証し、モデルを調整します。
6. 5 階層に拡張する前に、シンプルな 3 階層モデルから始めます。

よくある落とし穴

• すべての資産を「重要」と分類してしまい、階層化の目的を損なう
• システムの用途変更や廃止後に重要度スコアを更新しない
• ビジネスの背景を考慮せず、技術的な要素だけを使用する
• 資産の重要度に関係なく、一律の SLA を適用する
• 監査と一貫性のためのスコアリング方法を文書化しない

関連スキル

• performing-cve-prioritization-with-kev-catalog
• building-vulnerability-aging-and-sla-tracking
• performing-business-impact-analysis
• implementing-asset-management-program