📚 课程目录第3章基线制定方法论

3. 基线制定方法论：资产梳理、威胁建模、风险分析、控制措施映射

说实话，很多团队做基线，上来就翻等保要求或者CIS Benchmark，一条一条对着配。配完发现要么太严业务跑不起来，要么漏了关键风险。我早年也踩过这个坑。

后来我总结出一套方法，四个步骤：资产梳理 → 威胁建模 → 风险分析 → 控制措施映射。每一步都有坑，咱们一个一个说。

3.1 资产梳理：你得先知道家里有什么

你想想看，连自己有多少台服务器、跑什么系统、开什么端口都不知道，你怎么定基线？

我个人习惯，先做三件事：

硬件资产盘点：服务器型号、序列号、物理位置、维保状态。
软件资产盘点：操作系统版本、内核版本、中间件、数据库、第三方组件。
网络资产盘点：IP地址、开放端口、服务协议、网络区域归属。

我在项目中遇到过一家金融客户，资产清单里写着“CentOS 7.9”，结果上去一看，内核还是3.10的，一堆高危漏洞。所以光看版本号不够，得看实际运行状态。

小技巧：用自动化工具做资产发现，比如Nmap扫端口、Ansible收集facts、或者用CMDB的API拉数据。别用手工Excel，你永远不知道Excel里有多少“僵尸资产”。

资产梳理的输出，应该是一张资产清单表，至少包含以下字段：

资产ID	主机名	IP地址	操作系统	关键服务	所属区域	负责人
SRV-001	web-prod-01	10.0.1.10	CentOS 7.9	Nginx 1.20	DMZ	张三
SRV-002	db-prod-01	10.0.2.20	Ubuntu 20.04	MySQL 8.0	内网	李四

3.2 威胁建模：坏人会怎么搞你？

资产清楚了，接下来得想想谁会攻击你、怎么攻击。威胁建模不是玄学，是有套路的。

我常用的方法是STRIDE模型，微软搞出来的，六个维度：

Spoofing（假冒）：攻击者冒充合法用户或系统。
Tampering（篡改）：数据在传输或存储中被篡改。
Repudiation（抵赖）：用户做了操作但不承认。
Information Disclosure（信息泄露）：敏感数据被偷看。
Denial of Service（拒绝服务）：让系统不可用。
Elevation of Privilege（权限提升）：普通用户拿到管理员权限。

举个例子，一台对外暴露的Web服务器：

Spoofing：攻击者伪造源IP发起请求。
Tampering：中间人篡改HTTP响应。
Information Disclosure：目录遍历漏洞泄露配置文件。
DoS：CC攻击打满连接数。
Elevation of Privilege：通过WebShell提权到root。

  核心思路：威胁建模不是要穷举所有攻击，而是找出最可能发生、影响最大的那几个。别在“外星人入侵”上浪费时间。

3.3 风险分析：哪些事必须马上管？

威胁列了一堆，但资源有限，不可能全堵上。这时候需要做风险分析，给威胁排个优先级。

我习惯用风险 = 可能性 × 影响程度这个公式。简单粗暴，但够用。

举个例子：

威胁	可能性（1-5）	影响程度（1-5）	风险值	优先级
SSH弱口令爆破	5	5	25	高
Web目录遍历	3	4	12	中
日志未审计	2	2	4	低

风险值超过15的，必须纳入基线。10-15的，看情况。低于10的，先放一放。

注意：风险分析不是一次性的。业务变了、漏洞爆了、新攻击手法出来了，都得重新评估。我曾经见过一个团队，基线定完三年没动过，结果被Log4j打了个措手不及。

3.4 控制措施映射：把风险变成可执行的配置

最后一步，也是最关键的一步：把风险转化成具体的、可自动校验的配置项。

比如，针对“SSH弱口令爆破”这个高风险：

控制措施1：禁止root直接SSH登录 → 配置 PermitRootLogin no
控制措施2：使用密钥认证，禁用密码登录 → 配置 PasswordAuthentication no
控制措施3：限制SSH登录IP → 配置 AllowUsers 或防火墙规则
控制措施4：启用登录失败锁定 → 配置 pam_tally2 或 fail2ban

这些措施，每一条都要能写成可自动校验的规则。比如：

# 检查SSH配置
grep "^PermitRootLogin" /etc/ssh/sshd_config | grep -q "no"
if [ $? -eq 0 ]; then
    echo "PASS: root登录已禁用"
else
    echo "FAIL: root登录未禁用"
fi

我个人习惯，把控制措施映射成一张基线规则表：

风险ID	风险描述	控制措施	校验命令	预期结果
RISK-001	SSH弱口令爆破	禁用root直接登录	`grep '^PermitRootLogin' /etc/ssh/sshd_config`	no
RISK-002	SSH弱口令爆破	禁用密码认证	`grep '^PasswordAuthentication' /etc/ssh/sshd_config`	no
RISK-003	日志未审计	开启auditd	`systemctl is-active auditd`	active

有了这张表，后面的自动化校验就水到渠成了。

3.5 方法论全景图

下面这张图，把这四个步骤串起来了。你可以把它贴在工位上，每次做基线都看一眼。

3.6 避坑指南

最后，分享几个我踩过的坑：

别跳过资产梳理：我曾经接手一个项目，客户说“就20台机器”，结果一扫描发现还有5台没人知道的测试机在跑生产服务。嗯，那5台机器一个补丁都没打。
威胁建模别太学术：STRIDE的六个维度都过一遍就行，别纠结“这个算Tampering还是Spoofing”。实战中，威胁是混合的。
风险分析别搞复杂：什么蒙特卡洛模拟、贝叶斯网络，说实话在基线制定这个场景里用不上。简单乘一下，排个序，够了。
控制措施一定要可自动化：如果一条基线规则没法用脚本验证，那它大概率也执行不下去。人都是懒的，手动检查一次两次还行，长期肯定崩。