---

name: performing-asset-criticality-scoring-for-vulns description: 开发并应用多因素资产关键性评分模型，根据业务影响、数据敏感性和运营重要性对漏洞优先级进行加权。 domain: cybersecurity subdomain: vulnerability-management tags: [asset-criticality, vulnerability-prioritization, risk-management, cmdb, business-impact, crown-jewels, asset-classification] version: "1.0" author: mahipal license: Apache-2.0

针对漏洞执行资产关键性评分

概述

资产关键性评分（Asset Criticality Scoring）为每个 IT 资产分配业务影响评级，使漏洞修复工作集中于对组织风险最大的系统。没有关键性背景，测试服务器上的 CVSS 9.0 漏洞与支付处理数据库上的相同漏洞会得到同等紧急处理。本技能涵盖构建多因素评分模型，纳入数据敏感性、业务功能依赖性、监管范围、网络暴露和可恢复性，创建 1-5 关键性等级，直接调整漏洞修复 SLA。

前置条件

• 配置管理数据库（CMDB）或资产清单
• 业务影响分析（BIA）数据
• 数据分类策略
• 网络架构文档
• 业务单元负责人的干系人输入

核心概念

资产关键性评分模型

因素	权重	分数范围	描述
业务功能影响	25%	1-5	所支撑业务流程的关键程度
数据敏感性	25%	1-5	处理/存储数据的类型和敏感性
监管范围	15%	1-5	监管要求（PCI、HIPAA、SOX）
网络暴露	15%	1-5	面向互联网与仅内部使用
可恢复性	10%	1-5	RTO/RPO 要求、灾备能力
用户群体	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:
    """多因素资产关键性评分引擎。"""

    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, "皇冠宝石", -0.50),
        (3.5, 2, "高价值", -0.25),
        (2.5, 3, "标准", 0.00),
        (1.5, 4, "低影响", 0.25),
        (1.0, 5, "最小", 0.50),
    ]

    def score_asset(self, 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": "最小", "sla_modifier": 0.50}

    def adjust_vuln_sla(self, base_sla_days, asset_tier_data):
        """根据资产关键性调整漏洞 SLA。"""
        modifier = asset_tier_data["sla_modifier"]
        adjusted = int(base_sla_days * (1 + modifier))
        return max(1, adjusted)  # 最短 1 天 SLA

步骤 2：与漏洞优先级集成

def apply_criticality_to_vulns(vulns_df, asset_scores):
    """用资产关键性背景丰富漏洞数据。"""
    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", "标准")

        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