甲方安全运营体系第一年怎么建？四季度排期 + 八模块最小可用版本

见过太多这样的甲方安全运营团队：防火墙、WAF、EDR、SIEM 全买了，等保三级也过了，勒索软件进来还是全线失守；每天上万条告警，真正的攻击从眼前过去；漏扫报告月月出，高危堆成山，业务一句"影响稳定"就压着不修；年底申请预算，老板一句"安全只花钱"就打回来。

这些问题的根子不在技术，在于没有运营。设备是静态的，攻击是动态的；买了一堆能力，没人把它们串成一条能每天转起来的流水线。

但"建体系"这三个字最容易把人带偏——照着大厂方案列八大模块、四大支撑，写完一百页 PPT，落地的时候发现：三个人干不了，预算批不下来，业务不配合。

这篇不讲体系应该长什么样，讲第一年怎么排期、每个模块最小做到什么程度算能用、三个人怎么分工。如果你刚接手一个团队或者刚被要求"把安全运营做起来"，这篇是给你排期用的。

一、安全运营第一年：先接受「不要全上」

八个模块全铺开，结果一定是每个都做了 20%，每个都不堪用。正确做法是按"依赖关系"排序——有些模块是地基，没有它后面的都是空转。

依赖关系其实很简单：

• 资产不清，告警就无法判断影响面。你不知道被打的是核心库还是测试机，就没法定优先级。
• 日志不全，事件就无法溯源。只有边界日志，进来看不到主机侧，等于只能看到门口有人进，不知道他进了哪个房间。
• 闭环不通，做过的事就无法证明。修了多少、快了多少，没有数据就只能靠嘴说。

所以顺序是：底座（资产+日志）→ 闭环（漏洞+事件）→ 合规与度量 → 价值呈现。这个顺序反了，前面做的都要返工。

二、第一年四季度排期

下面这张表是我实际推过两轮的节奏。每一格都有可验收的产出，没产出就说明这一季没做成。

Q1 最容易拖，也最不该拖。资产和日志是死功夫，没有技巧，但它决定了后面所有事情的可信度。

三、Q1：底座怎么搭才算"能用"

底座的验收标准不是"买了平台"，是"能回答三个问题"：

1. 这个 IP 是谁的、跑什么业务、归谁负责？
2. 这台机器过去 30 天的登录、进程、网络连接能不能查到？
3. 出了高危告警，15 分钟内能不能找到人？

三个问题答不上来，平台买得再贵也是摆设。

资产台账不要一上来就求全。先做核心资产——那些"停了业务就停"的系统。用云平台、虚拟化、DHCP、DNS、堡垒机、EDR 六个数据源交叉，差额就是盲区。具体方法我在 甲方安全新人第一个月做什么 里写得很细，这里不重复。

日志采集要先定"采什么"，再定"用什么采"。新人常犯的错是"全采"，结果存储成本爆掉、查询慢到没人用。第一年采这五类就够：

保留期不是随便定的：认证和数据操作这两类要留够半年，因为事后追查往往在三个月后才启动。

告警通道只要一条，但必须通到人。别一上来就搞分级、搞工单、搞自动化编排。先保证：高危告警能推到值班人手机上，且有人确认。这条链路不通，后面所有告警治理都是白做。

四、Q2：闭环怎么算"跑通"

闭环跑通的标志不是流程图画完了，是季度内有三次完整记录：从发现、研判、处置、复测到复盘，每一步有时间戳、有责任人、有证据。

漏洞这一侧，核心是 SLA 分级。不要用"高危 7 天、中危 30 天"一刀切，按"能不能被远程直接利用 × 资产暴露面"两个维度定，具体分级表和配置方法在 漏洞管理闭环怎么建 里。

事件这一侧，核心是处置顺序固定下来。半夜被叫起来，人的本能是"赶紧弄好"，但重启一次证据就没了。这个顺序不能靠临场判断，要写成清单贴在值班位上。

复盘的产出也要固定：不是写检讨，是落到三个具体动作——这个入口能不能封、这个动作能不能被检测、这个扩散路径能不能打断。三条都进台账，下季度回看。

五、Q3：安全运营的合规与度量，别做成两套

合规和度量最容易变成两张皮：合规那边准备一堆材料应付测评，度量这边另做一套报表给领导看。两套东西口径不一致，谁都不信。

做法是一套数据两种切法。同一份基线核查结果，对测评师展示"符合/不符合 + 证据"，对领导展示"符合率趋势 + 高风险项"。同一份漏洞台账，对研发是待办清单，对业务是逾期率。

等保这块具体怎么落、测评现场怎么配合，看 等保 2.0 定级备案全流程 和 等保 2.0 整改与测评验收，两篇是接续的。

度量指标第一年只要六个，多了没人看：

这六个数的特点是都能自动化算出来，而且都能被人为努力改善。要避免的指标是"发现漏洞数""拦截攻击次数"——这类数字只反映攻击量，不反映你的能力。

六、八个模块的最小可用版本

原文那种"八大模块"列法没错，但没说每个模块做到什么程度算够。下面这张表是我认为第一年各模块的 MVP（最小可用版本）：

这张表的价值在于"右边一列"——明确写出第一年不做什么，才不会被各种新需求拖着走。每加一件事，就要砍掉一件事，否则团队会被无限摊薄。

七、安全运营日历：日、周、月、季各做什么

体系能不能持续，取决于有没有固定的节奏。下面这套日历是三个人的团队能跑下来的强度：

日巡检最容易流于形式。建议把它做成一张勾选清单，每项都有明确的判断标准，而不是"看一下有没有异常"这种没法验证的描述。

告警复盘时的固定动作是看 Top5 规则：如果某一条规则占了总告警量的一半以上，先调这条，比全量调阈值有效得多。Wazuh 这类平台里怎么看 Top 规则、怎么调，可以看 Wazuh 搭 SIEM+XDR 怎么落地。

八、三个人怎么分工

大部分甲方安全团队就是三到五个人。分工不是按"八大模块"切（切不动），而是按"一天里的动作类型"切：

人更少的时候，运营岗和技服岗由同一人兼，但管理岗的跨部门协调不能省。安全在甲方是支撑部门，协调能力决定了你能不能推动事情，这活技术强的人往往干不好。

九、向老板要预算，用风险语言不用技术语言

这是最容易被忽略的一环。技术出身的人讲预算，习惯讲"我们需要部署 XX 因为 XX 有风险"，老板听到的是"又要花钱"。

有效的说法是三段：

1. 现在的暴露是什么：不是"存在高危漏洞 137 个"，而是"核心订单系统的 3 个高危漏洞已逾期 40 天，其中 1 个可被未授权远程利用，一旦被利用，订单数据可被读取"。
2. 不做的后果是什么：能算就算钱（停业损失、赔付、监管罚款），算不了就给同行案例。
3. 要什么、换什么：不是"申请预算 80 万"，而是"投入 80 万，把高危平均修复时长从 38 天压到 14 天，把核心资产覆盖率从 60% 提到 90%"。

第三段最关键——给一个可验收的承诺。老板不怕花钱，怕花了钱不知道买到了什么。

预算批不下来，先做这三件不要钱的事

大部分团队第一年拿不到预算，这很正常。别停在那儿等，先把不花钱的部分做出来，用结果换预算。

第一件：把资产台账做干净。不花钱，只要肯花时间。做完之后你能说出"我们有 47 个对外暴露的服务，其中 11 个跑了三年以上没打过补丁"，这句话本身就是预算申请里最硬的部分。

第二件：用现有工具做一次基线抽检。手工也行，抽 20 台核心主机查 10 项基线，出一份符合率报告。这份报告能同时喂给合规和领导，两边都用得上。

第三件：把一次真实告警的处置过程记录下来。从告警产生到定性用了多久、谁在处理、卡在哪一步。这个记录会暴露你缺什么——是缺人、缺日志、还是缺流程。拿着它去申请，比拿着产品清单有用。

这三件事做完通常要两到三个月，正好是 Q1 的长度。等 Q1 结束你有了数据，Q4 的预算申请就不是"我想要"，而是"这是现状，这是差距，这是投入产出"。

十、七个误区，说具体的

原文列了七个误区，但写得太抽象。我按实际踩过的写成可判断的形式：

误区一：先买平台再想流程。判断标准：如果平台上线三个月，上面的流程还是厂商实施时配的那套，没改过，就是这个误区。

误区二：把合规当目标。判断标准：问团队"我们最怕出什么事"，如果答案只有"测评不过"，就是这个误区。

误区三：告警越多越安全。判断标准：日均告警量在涨，但研判后的真实事件数没变，说明只是在制造噪音。

误区四：安全是安全部门的事。判断标准：漏洞整改的工单有没有派到业务侧的具体人，还是全压在安全团队自己手里改。

误区五：只报数字不报趋势。判断标准：月报里只有"本月发现 X 个、修复 Y 个"，没有环比和原因分析。

误区六：一次建完就完事。判断标准：制度文件超过一年没更新过。

误区七：不演练。判断标准：过去一年没做过桌面推演。没演练过的预案，真出事时一定用不上——因为联系人早就换人了。

十一、什么时候算"体系建成了"

没有建成的那天。但如果出现这三个迹象，说明它已经能自己转了：

• 你休假两周，日巡检和周报照常出；
• 业务方主动来找你"这个新系统上线前要不要看一遍"；
• 领导在别的会上引用你的数据。

第三条最能说明问题——当你的数据被别人拿去用，说明它已经成了决策依据，而不是一份交上去就没人看的报告。