4.4 安全运营

概述与动机

预防是必要的，但永远不够。坚定的攻击者、新出现的漏洞，以及单纯的人为失误，都意味着总会有一些威胁溜过你的防线。安全运营是一门学科，专注于快速发现这些威胁、妥善响应，并把从中学到的东西反馈回去，让防御变得更加坚固。它决定了一次事故是在几分钟内被控制住，还是在无人察觉的情况下潜伏数月。

在一个大型组织中，安全运营必须能够以规模和速度运作。成千上万个服务会产生海量的日志。每周都会披露数百个新漏洞。部署永不停止。手工的、作坊式的运营根本无法跟上节奏。答案是把安全嵌入交付流水线（DevSecOps），自动化检测与响应，并锻炼出在事故发生时能够沉着应对的能力。对于政府而言，安全运营还承担着法定义务：强制性的事件报告时限、协调一致的漏洞披露，以及能够经得起法律审查的取证严谨性。

本章涵盖如何把安全整合进流水线、如何管理漏洞与打补丁、如何响应事故并开展取证、如何通过 SIEM 和 SOAR 运行检测，以及如何通过红队、紫队演练和渗透测试来验证防御能力。

关键原则

自动化常规工作。 让机器处理扫描、关联分析和重复性的响应工作，使人力能够专注于需要判断力的事情。
把安全前移进流水线。 测试和关卡设在 CI/CD（持续集成与持续交付）之中，在工程师已经在工作的地方提供快速反馈。
假定已被突破，并做好准备。 在真正需要之前就演练好事故响应；事故发生的当下不是即兴发挥的时候。
衡量并缩短时间。 平均检测时间和平均响应时间是最重要的两个指标。
无责学习。 每一次事故和未遂事件，都应变成一个能加固系统的教训，而不是一场追究责任的问责。
以对抗方式验证防御。 用真实攻击者会采用的方式测试你的安全，然后修复他们发现的问题。
检测工程是一款产品。 把检测规则当作代码来对待：纳入版本控制、经过测试，并持续改进。

建议

把 DevSecOps 构建进流水线

把自动化安全测试直接整合进持续集成与交付，让反馈能在几分钟内送达工程师：

SAST（静态应用安全测试）在代码提交时分析源代码中的易受攻击模式。
DAST（动态应用安全测试）对正在运行的应用程序进行探测，寻找可被利用的缺陷。
SCA（软件成分分析）标记出已知存在漏洞的依赖项。
IaC 扫描在基础设施即代码部署之前检查其中不安全的配置。
密钥扫描阻止凭据进入代码仓库。

要毫不留情地调优这些工具，以控制误报率。一个总是”狼来了”的扫描器会被人忽视。设置基于风险的关卡：对高严重性、高置信度的发现予以拦截，其余的则跟踪记录而不阻断交付。你想要的是一个快速、可信的信号，而不是一堵噪声之墙。

系统化地管理漏洞并打补丁

源源不断的漏洞需要一套系统化的、有优先级排序的流程，而不是每出现一条新闻标题就陷入一次恐慌。

维护一份准确的资产清单，这样你才知道任何一个特定漏洞可能会影响到什么。
根据真实风险来确定修复的优先级：综合考虑严重性、可利用性（它是否正在野外被利用？）、暴露程度和资产关键性，而不是仅仅按原始评分打补丁。
按严重性等级定义并强制执行修复服务水平协议（remediation SLA），并衡量其遵守情况。
在能够安全实现自动化的地方，尽量自动打补丁，尤其是针对基础设施和依赖项。
运行一个协调一致的漏洞披露（coordinated vulnerability disclosure）项目，配有一个明确的接收渠道，并在合适的情况下设立漏洞赏金计划（bug bounty），让外部研究人员能够负责任地报告漏洞，而不是公开倾倒出来。

为事故响应做好准备并加以执行

事故发生时，一套经过演练的流程，比任何工具都更有价值。

维护一份事故响应计划，明确定义角色（事故指挥官、沟通负责人、调查人员）、严重性分级，以及升级路径。
建立清晰的阶段：准备、检测与分析、遏制、根除、恢复，以及事故后评审。
妥善保存证据以供取证使用：以有记录的监管链（chain of custody）来采集日志、内存和磁盘镜像，让调查结果能够经得起法律考验、分析结果站得住脚。
提前规划好数据泄露沟通：由谁在什么时间线上通知客户、监管机构和公众，法务和公关部门如何参与。监管方面的时钟（通常是 72 小时或更短）从发现之时就开始计时。
定期开展桌面演练，让团队在真正的危机来临之前就熟悉这套计划，并进行无责的事故后评审，产出具体的改进措施。

用 SIEM 和 SOAR 运营检测，并对检测能力进行工程化建设

把你的安全信号汇聚起来，并大规模地据此采取行动。

使用 SIEM（安全信息与事件管理）来汇聚并关联整个体系中的日志和事件，让可疑模式浮现出来。
使用 SOAR（安全编排、自动化与响应）来自动化分诊和响应操作手册：丰富告警信息、隔离主机、禁用凭据，并针对常规步骤直接开立案件，无需等待人工处理。
践行检测工程（detection engineering）：把检测规则当作纳入版本控制、经过测试的代码来对待，使其与 MITRE ATT&CK 之类的框架对齐，衡量它们的真阳性率和假阳性率，并持续改进对真实对手手法的覆盖度。
确保应用程序和基础设施上都有全面的、防篡改的日志记录；你无法检测你没有记录下来的东西。

用红队、紫队演练和渗透测试来验证防御

以攻击者的方式测试你的防御，是了解它们是否真正有效的唯一途径。

渗透测试为特定系统提供聚焦的、某一时间点的评估，通常是为了满足合规要求。
红队演练（Red teaming）模拟一个在你的环境中追求特定目标的真实对手，不仅测试防御能力，也测试检测和响应能力。
紫队演练（Purple teaming）把攻击方（红队）和防御方（蓝队）协作地聚集在一起，让每一次模拟攻击都能立即改进检测和控制措施，把一次演练变成一项持久的能力。
把所有发现反馈回检测工程、修复工作和培训之中。

权衡取舍：利与弊

决策	优点	缺点
阻断式流水线关卡	阻止已知问题被交付上线	摩擦大，误报让团队感到沮丧
非阻断式扫描	摩擦小，交付速度快	问题可能被带上线；需要纪律来修复
自建安全运营中心（SOC）	上下文深入，完全可控	成本高，难以做到 24 小时全天候配备人手
托管检测与响应服务	24 小时全覆盖，专业能力随需调用	上下文较浅，依赖供应商
自动打补丁	速度快，能迅速关闭风险窗口	存在引入破坏性变更的风险
频繁的红队演练	验证真实可信，能发现真正的缺口	成本高，资源消耗大
漏洞赏金计划	众包式发现，覆盖面好	分诊负担重，赏金支出，噪声多

核心张力在于速度与保障之间，以及覆盖面与成本之间。阻断式关卡和自动打补丁能最大化保障，但会增加摩擦和风险。非阻断式方法速度更快，但依赖于后续的持续跟进。全天候检测在规模化场景下是必不可少的，但自建成本高昂，这促使许多组织转向混合模式。可持续的路径是把高置信度的常规工作自动化，把人力的注意力留给真正需要判断力的事情，并依据实测结果而非恐惧来持续调优这种平衡。

与团队讨论的问题

你们按严重性划分的修复 SLA 是什么，实际上又是什么在强制执行它们？ 源源不断的漏洞需要一套系统化的、有优先级排序的流程，而不是每出现一条新闻标题就陷入一次恐慌，按严重性等级设定的 SLA 正是你保持节奏的方式。确定你的时钟（例如，严重级别几天内、高级别几周内），同样重要的是，你如何衡量遵守情况，以及当截止日期被错过时由谁负责。根据真实风险来确定优先级，综合考虑严重性与野外可利用性、暴露程度和资产关键性，而不是仅仅按原始的 CVSS 评分打补丁。拿出你当前按发现时间和严重性排序的未修复漏洞积压清单，因为那些超出了修复窗口却仍未修补的严重漏洞，才是真正重要的证据。如果这个 SLA 没有强制执行、也没有负责人，那它就只是一个愿望，而没有修复配套的扫描只会积累审计债务和一种虚假的安全感。
当事故在凌晨两点发生时，谁是事故指挥官，监管方面的时钟又会以多快的速度开始计时？ 一套经过演练的流程比任何工具都更有价值，因此你需要在危机来临之前，就把明确的角色（事故指挥官、沟通负责人、调查人员）、明确的严重性等级和升级路径写下来。监管方面的时钟通常是 72 小时或更短，从发现之时就开始计时，因此要提前决定由谁通知客户、监管机构和公众，并确认法务和公关部门已经参与其中。以有记录的监管链来保存取证证据，必须在任何人重建一台被入侵的主机之前完成，否则你就失去了理解或证明究竟发生了什么的能力。拿出你上一次桌面演练的日期，因为如果那是很久以前，或者从未进行过，你的计划就是未经检验的。对政府团队而言，法定的报告截止日期让这件事没有商量的余地，因此要演练的不仅是技术响应，还有通知路径。
你会让 SOAR 在没有人工介入的情况下自主采取哪些常规响应行动？ 自动化是一种力量倍增器，让一个精简的团队也能覆盖一个庞大的体系，而这里真正重要的指标是平均响应时间，自动化操作手册能把它从几小时缩短到几分钟。决定哪些高置信度的动作（隔离一台主机、吊销一个凭据、开立一个案件）你信任让它自动运行，哪些需要先经过人工判断。风险在于误报触发了一次具有破坏性的动作，因此要把自动化与检测质量绑定，并毫不留情地调优，因为一个总是”狼来了”的系统会被关掉。拿出你当前的告警量和误报率，因为这些数字会告诉你今天哪些操作手册可以安全地自动化。如果每一个响应步骤都要等待人工处理，你就无法在规模化场景中跟上节奏，而驻留时间（dwell time，它决定了数据泄露的成本）会一直居高不下。
流水线中的哪些发现会阻断一次发布，哪些只是被跟踪记录，又是谁在把误报率保持在足够低的水平，使工程师依然信任这道关卡？ 一个总是”狼来了”的扫描器会被人忽视，一旦工程师对一道关卡失去信任，他们就会游说要求把它彻底移除，因此 DevSecOps 的价值取决于信号质量，而不是原始的覆盖面。这种张力是真实存在的：拦截得太少，存在漏洞的代码就会被交付上线；拦截得太多，就会增加摩擦、拖慢交付、消耗善意。拿出每个扫描器（SAST、DAST、SCA、IaC 和密钥扫描）的真阳性率和假阳性率、团队多久会覆盖或压制一次关卡，以及那些仅被跟踪而未被修复的发现存在了多久。对于运行着成百上千条流水线的企业或政府机构而言，要在中央层面制定拦截与跟踪的策略，并用数据来调优它，因为各团队之间随意不同的关卡设置，既会造成审计缺口，也会让人觉得安全措施反复无常。
你有多大信心，认为你们的检测规则仍然覆盖了真实攻击者会使用的手法，又是谁把它们当作经过测试的、版本受控的代码来负责？ 随着你的环境和对手不断演变，检测规则会悄悄地失效，因此一套去年看起来面面俱到的规则集，很可能在一次事故最终暴露出这个缺口之前很久就已经失去了覆盖能力。把检测规则当作代码来对待（）纳入版本控制、经过测试，并映射到 MITRE ATT&CK 之类的框架（）正是把一门工程实践与一堆过时告警区分开来的关键，然而它要与实时分诊工作争夺同样稀缺的分析师时间。拿出你当前的 ATT&CK 覆盖地图、你最重要的那些检测规则实测出的真阳性率和假阳性率，以及你上一次紫队演练的结果，因为协作式的红蓝对抗测试是证明哪些检测规则真正能触发的最快方式。在可能被强制要求采用某个框架的企业和政府场景中，把每一条检测规则都绑定到一位指定的负责人和一个评审节奏上，因为一个没人维护的覆盖能力，往往要等到数据泄露发生之后，你才会发现自己已经失去了它。
你是自建检测与响应能力，购买托管检测与响应服务，还是把两者结合起来，你有没有核算过真正的全天候覆盖需要花多少钱？ 驻留时间决定了数据泄露的成本，因此那些无人覆盖的时段（夜晚、周末、节假日）恰恰是未被发现的入侵者造成最大破坏的时候，然而自建一个 24 小时全天候的安全运营中心成本高昂，也很难长期维持。这是一种在上下文与可控性和成本与覆盖速度之间的权衡：自建团队深谙你的体系，但构建起来既慢又贵，而一个托管服务商能以较薄的上下文和对供应商的依赖为代价，提供全天候的即时专业能力。拿出你当前的覆盖时长、非工作时段的平均检测和响应时间、告警量，以及一个诚实的判断：你能否招募并留住一个自建中心所需要的分析师。对于政府和受监管的企业而言，要权衡数据驻留、人员安全审查，以及服务商必须能够满足的法定报告义务，并确认合同保留了法律程序所要求的取证严谨性和监管链。

行业视角

初创企业。 速度和生存排在第一位，因此要把安全当作你已经在使用的工具所附带的副产品来购买，而不是专门配备一个运营团队。把免费的扫描器接入 CI，在提交代码时就拦截密钥泄露和已知存在漏洞的依赖项，把日志转发到一个低成本的托管服务，并设置少量高价值的告警，在真正需要它之前，先写好一页纸的事故计划（打给谁、如何轮换凭据、在重建之前先做快照）。你最稀缺的资源是工程注意力，因此要把常规工作自动化，抵制住建立一个你无法维持运转的安全运营中心的冲动。

小型企业。 没有专职的安全专家、预算又紧张的情况下，依靠托管检测与响应服务，以及你的平台中已经内置的安全功能。把打补丁和资产清点当作杠杆最高的习惯：知道你在运行什么，让它保持最新，并按严重性强制执行一个简单的修复截止日期。优先选择能为你处理全天候监控、协调一致的漏洞披露接收，以及取证采集的供应商，并演练那件你无法外包出去的事（）决定由谁来宣布一起事故、由谁去和客户沟通。

企业。 挑战在于跨众多团队和成百上千条流水线保持一致性：一套共享的拦截与跟踪关卡策略、在全组织范围内强制执行的修复 SLA、一个配有实测数据支撑的检测能力的 SIEM 和 SOAR 平台，以及能把每一次演练都转化为新的覆盖能力的紫队演练。把安全运营当作一个投资组合来管理，配有平均检测和响应时间、SLA 遵守情况和检测精确度的仪表盘，并有意识地决定在哪些地方自建的深度胜过托管的规模。明确地为分诊和调优所需的人工监督成本做预算，因为自动化转移的是工作量，而不是消除了它。

政府。 采购规则、透明度和公共问责塑造着每一个选择。法定的事故报告截止日期和协调一致的漏洞披露是义务，而不是可选项，因此要像演练技术响应一样，仔细地演练向国家主管机构的通知路径，并在一条能够经得起法律审查的监管链下妥善保存取证证据。优先选择能让检测逻辑和数据保持可移植性的合同，要求任何托管服务商都满足数据驻留和安全审查方面的要求，并期望红队评估和持续扫描能为一个能够赢得公众信任的授权流程提供支撑。

案例

初创企业。 一家没有安全运营中心的初创公司，把免费的扫描器接入了它的 CI 流水线，这样密钥泄露和已知存在漏洞的依赖项就能在提交代码时被捕获，并且只对高置信度的发现进行拦截，以免两名工程师被噪声淹没。他们在真正需要之前就写好了一页纸的事故计划：打给谁、如何轮换凭据，以及在重建一台被入侵的主机之前先对其做快照，以便了解究竟发生了什么。他们把日志转发到一个低成本的托管服务，并针对那些真正能预示数据泄露的事件设置了少量告警，这样一个问题会在几小时内浮现，而不是像偶然发现那样要等上几个月。

企业。 一家软件即服务公司在每一条流水线中都运行 SAST、SCA、IaC 和密钥扫描，只对高严重性、高置信度的发现进行拦截，其余的则在一个带有修复 SLA 的仪表盘上被跟踪记录。一个 SIEM 为一个 SOAR 平台提供数据，后者会对高置信度的告警自动隔离主机、吊销凭据，把平均响应时间从几小时缩短到几分钟。每季度针对 MITRE ATT&CK 手法开展的紫队演练，会直接生成新的检测规则，持续弥补覆盖缺口。

政府。 一家联邦机构运营着一个安全运营中心（SOC），并按法定期限向国家网络安全主管机构进行强制性事故报告。它按照政策要求运行一个带有公开接收渠道的协调一致的漏洞披露项目，并在适合法律程序的严格监管链程序下保存取证证据。每年的红队评估和持续的漏洞扫描，为该机构持续进行的授权流程和基于风险的修复 SLA 提供支撑。

商业案例：动机、投资回报率与总拥有成本

关于安全运营的商业案例，几乎所有的一切都归结为驻留时间：攻击者未被发现的时间越长，数据泄露的代价就越高。研究一再表明，被迅速控制的事故所花费的成本，要远远低于那些持续数月之久的事故。总拥有成本包括工具（SIEM、SOAR、扫描器）、检测与响应所需的人力配备或托管服务，以及构建和演练事故处理流程所需的时间。与之相对的是不投资的代价：一次被延迟发现的数据泄露，在各系统间不断蔓延，招致监管罚款、强制通知、诉讼和声誉损害，而未经演练的响应所带来的混乱，还会让这一切雪上加霜。

投资回报来自更快的检测和响应、让一个精简团队也能覆盖庞大体系的自动化，以及从每一次事故和演练中反馈回来的预防改进。DevSecOps 尤其能带来回报，因为它能在成本低廉的流水线阶段发现问题，而不是等到成本高昂又会公开曝光的生产环境阶段。当你向领导层证明这一点时，把你当前的平均检测和响应时间量化成数字，展示这些数字与驻留时间和成本之间的关联，并把自动化定位为一种能避免人力配置随体系规模同步膨胀的力量倍增器。对政府而言，要强调法定的报告和披露义务，使成熟的运营能力没有商量的余地。

反模式与陷阱

告警疲劳。 告警太多，以至于分析师屏蔽了它们，错过了那条真正重要的告警。
只扫描不修复。 产生了没人去修复的发现，制造出一种虚假的安全感和审计债务。
没有事故计划。 在危机中临场发挥，浪费掉关键的几分钟，并处理不当证据。
销毁证据。 在采集取证信息之前就重建了一台被入侵的主机，失去了理解或证明究竟发生了什么的能力。
评审中的问责文化。 惩罚响应人员，导致下一次事故被隐瞒或被防御性地处理。
只为合规而做的渗透测试。 每年做一次测试来满足审计人员，发现的问题一直被搁置，直到来年。
误报率高的拦截式关卡。 不断侵蚀信任，直到工程师要求彻底移除这些关卡。
设置后就不再管的检测规则。 随着环境和对手不断演变而悄悄失效的规则，覆盖能力在无声中流失。

成熟度模型

第一级：启动。 安全运营是临时的、被动式的。安全测试是人工进行的，且很少发生，没有集中的日志记录或 SIEM。没有事故计划，因此响应完全靠临场发挥。打补丁只有在新闻标题施加压力时才会发生，防御措施从未经受过对抗性测试。

第二级：发展。 基本实践开始出现，但在各团队之间并不一致。一些流水线运行了扫描器，另一些则完全没有，集中日志记录只是零星存在。一份基本的事故计划已被记录下来，但很少被演练，打补丁遵循松散的时间表，每年一次的渗透测试仅仅满足了合规要求，却没有带来多少实质性改变。覆盖面和严谨程度取决于你问的是哪个团队。

第三级：标准化。 实践被文档化，并在全组织范围内被强制执行。带有基于风险的关卡的全面 DevSecOps 扫描被一致地应用，一个 SIEM 关联各种事件，初步的 SOAR 操作手册也已运行起来。事故响应通过桌面演练和无责评审进行演练，按严重性设定的修复 SLA 由指定的负责人强制执行，协调一致的漏洞披露和定期的红队演练成为常态，而非例外。

第四级：管理。 运营依据基线被度量和控制。平均检测和响应时间、按严重性等级划分的 SLA 遵守情况、扫描覆盖率、检测规则的真阳性率和假阳性率，以及驻留时间，都被记录在仪表盘上，并按固定节奏被评审。检测规则携带映射到 MITRE ATT&CK 的实测精确率和召回率，自动化决策依据的是误报数据而不是一厢情愿的希望，一项偏离基线的指标会触发一个明确定义的响应，而不是被无人察觉地忽略。

第五级：协同。 安全运营被持续改进，在整个组织中被整合，并具有适应能力。检测工程、紫队演练、修复工作和事故评审共同汇入一个循环，随着新的对手手法出现而不断调整。自动化操作手册在整个体系范围内处理常规工作，使人力能够专注于判断力，安全与交付和风险一起被规划，每一次事故和演练都能可衡量地加固系统，同时核心指标持续走低。

讨论思路

流水线中的哪些发现应该阻断一次发布，哪些应该仅仅被跟踪记录？
自建安全运营中心、使用托管检测与响应服务，还是把两者结合起来，为什么？
你如何防止检测规则随着环境的演变而逐渐失效？
考虑到引入破坏性变更的风险，打补丁的自动化程度应该有多高？
在你们的文化中，一场真正无责的事故后评审是什么样子的？
你如何衡量红队和紫队演练是否真的在改进你们的防御能力？

关键要点

预防终究会失效；运营的存在正是为了快速检测和响应。
把 SAST、DAST、SCA、IaC 和密钥扫描嵌入流水线，配以基于风险的关卡。
依据真实的可利用性和资产关键性来确定打补丁的优先级，并置于强制执行的 SLA 之下。
提前演练事故响应，妥善保存取证证据，并预先规划好数据泄露沟通方案。
用 SIEM 和 SOAR 进行关联分析和自动化；把检测规则当作经过工程化、经过测试的代码来对待。
用渗透测试、红队演练和协作式紫队演练来验证防御能力。
驻留时间决定了数据泄露的成本，因此平均检测时间和平均响应时间才是最重要的指标。

参考文献与延伸阅读

National Institute of Standards and Technology, SP 800-61: Computer Security Incident Handling Guide
National Institute of Standards and Technology, SP 800-40: Guide to Enterprise Patch Management
MITRE, ATT&CK Framework
Anton Chuvakin and others, Logging and Log Management / SIEM literature
Jim Bird, DevOpsSec: Securing Software through Continuous Delivery
Richard Bejtlich, The Practice of Network Security Monitoring
FIRST, Coordinated Vulnerability Disclosure guidance and CVSS specification