performing-asset-criticality-scoring-for-vulns

为漏洞执行资产关键性评分

概述

资产关键性评分会为每个 IT 资产分配业务影响评级，使漏洞修复工作聚焦于对组织风险最大的系统。缺少关键性上下文时，测试服务器上的 CVSS 9.0 漏洞与支付处理数据库上的同一漏洞会被同等紧急地对待。本技能涵盖构建多因素评分模型，纳入数据敏感性、业务功能依赖、监管范围、网络暴露面和可恢复性，以创建 1-5 的关键性层级，直接调整漏洞修复 SLA。

何时使用

• 在开展涉及为漏洞执行资产关键性评分的 security assessments 时
• 在针对相关安全事件遵循事件响应流程时
• 在执行计划内的安全测试或审计活动时
• 在通过实际测试验证安全控制措施时

前提条件

• 配置管理数据库（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	核心资产	-50% SLA	域控制器、支付系统、ERP
2	3.5-4.4	高价值	-25% SLA	电子邮件服务器、HR 系统、CI/CD
3	2.5-3.4	标准	基准 SLA	内部应用、文件服务器
4	1.5-2.4	低影响	+25% SLA	测试环境、打印机
5	1.0-1.4	最低	+50% SLA	正在退役的系统、隔离实验室

数据敏感性评分

分值	分类	示例
5	受限/机密	PII、PHI、支付卡数据、商业秘密
4	保密	财务报告、HR 记录、源代码
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. 将关键性层级应用于漏洞 SLA，以实现与风险成比例的修复
5. 用实际事件影响数据验证评分，以校准模型
6. 先从简单的 3 层级模型开始，再扩展到 5 层级

常见陷阱

• 将所有资产都归类为“关键”，这会使分层失去意义
• 当系统被改作他用或退役时未更新关键性评分
• 只使用技术因素而缺少业务上下文
• 不论资产重要性都应用统一 SLA
• 未记录评分方法，无法支持审计和一致性

相关技能

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