performing-asset-criticality-scoring-for-vulns

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

## 概述
资产关键性评分（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：定义评分标准

```python
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：与漏洞优先级集成

```python
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