网硕互联帮助中心
很多企业的安全建设,都停留在"一年打一次攻防演练,演练完了就松一口气"的节奏上。红蓝对抗打得热闹,防守方绞尽脑汁堵漏洞,可演练一结束,那套临时抱佛脚建起来的检测规则和应急流程,很快就没人维护了。等到第二年演练再打,同样的问题又重新暴露一遍——攻防演练变成了"年终考试",而不是"日常体检"。
这份《常态化攻防及运营体系建设方案》讲的正是怎么打破这个死循环。方案的核心主张很直接——攻防演练的目的是检验体系和能力的效果,而"体系和能力"本身应该常态化运行,不能演练一结束就束之高阁。这份方案没有堆砌安全概念,而是用ATT&CK矩阵做检测能力建设的地图、用真实的钓鱼案例讲清楚攻击链路、用影子资产和失控云账号的具体案例暴露资产管理的漏洞、用告警聚合和联动阻断讲清楚怎么让安全运营真正跑起来。这是一份技术细节扎实、案例真实的安全运营实战方案,值得完整拆一遍。
一、为什么要强调"常态化"
方案开篇提出的问题很尖锐——企业面对的对抗对象有三个层次：渗透测试、众测、SRC（相对温和,以发现和上报漏洞为主)、红蓝对抗、HW（护网）、攻防演练（更贴近真实攻击,检验防守体系)、黑灰产、黑客、APT（真正的敌人,没有规则限制,持续存在）。
方案指出——“攻击力量、攻击手段更加丰富,边界和范围逐渐延展,对抗不断演进和升级”。这句话点出了一个残酷的现实：真正的攻击者不会按照攻防演练的时间表来,他们是全年候存在的。如果企业的安全能力只在演练期间"临时在线",演练之外的360天,防线其实是空的。
方案给出的核心结论是——“攻防演练的目的是所谓体系和能力的效果检验,'体系和能力’应该常态化运行”。换句话说,演练不是终点,而是对已经在日常运行的安全体系做一次抽查。方案用"安全产品&安全运营"这个对比,暗示了另一个关键点——光买安全产品不够,产品背后必须有持续运营的人和流程,才能真正发挥价值。这也是整份方案后续内容的主线——从检测能力建设,到资产管理,到运营效率,每一部分都在回答"怎么让安全能力持续在线"这个问题。
二、入侵检测&安全运营体系：用数字说话的成果
方案给出了一组具体的运营数据,展示了常态化安全运营体系实际运转的效果——规则数量550+、告警事件量20w+、自动化运营处置73.5%、发现真实安全风险事件2000+、HW期间抓到0day漏洞4个。
这组数据背后有几个值得关注的信号：
**规则数量550+**说明检测能力已经形成了相当规模的覆盖面,不是零散的几条规则。
**告警事件量20w+**说明安全运营团队面对的是海量告警,如果没有自动化处置能力,人工根本扛不住。
**自动化运营处置73.5%**是这组数据里最关键的指标——接近四分之三的告警能够自动化处置,说明这套体系已经从"人工盯屏幕"进化到了"机器先筛一遍,人只处理剩下的疑难案例"。这个比例直接决定了安全团队的人力能不能真正聚焦在高价值的分析和响应工作上,而不是被海量重复性告警淹没。
发现真实安全风险事件2000+和HW期间抓到0day漏洞4个,则是这套体系真正创造价值的证明——不是规则数量堆出来的花架子,而是真的能揪出实际威胁,甚至是未公开的0day漏洞。这组数据合在一起,构成了一个很好的说服素材——常态化运营体系不是纸上谈兵的概念,而是有真实产出的能力。
三、入侵检测能力的持续构建：用ATT&CK矩阵找地图、找方向
这是方案里方法论最系统的部分。方案先抛出了四个现实问题——“如何构建检测能力？该从何入手？有没有捷径？现实与差距？”，紧接着指出安全团队面临的真实挑战——“针对性场景、高级对抗;钓鱼失陷、出局;红队手法日渐多样化;对抗越来越深入”。
ATT&CK矩阵：帮助"识大局"的地图
方案给出的解法是引入ATT&CK矩阵,定位是"帮助我们识大局——差距分析和成熟度评估"。这个定位很精准——ATT&CK矩阵本身不是一个检测工具,而是一张攻击战术技术的地图,企业可以用这张地图来盘点"我们已经覆盖了哪些格子,还有哪些格子是空白的"。
方案给出的具体构建方法分三步——
第一步：找地图、找方向。以ATT&CK矩阵的技战术为参考,作为构建入侵检测能力的依据和方向;按照Tactic战术的重要优先级进行排序,将风险等级高的优先覆盖（如Credential Access凭证访问、Execution执行、Persistence持久化、Privilege Escalation权限提升等）。
第二步：检测落地。对可落地的Technique技术,实现基本的原理&手段&工具的检测覆盖（要求MITRE知识库上及网络上能搜罗到的攻击手段和工具都能检出);持续的对抗,发现新手段/工具、绕过技术,优化策略。
第三步：摸底细、知现状。筛选和摸底,哪些Technique技术当前可以快速落地,哪些当前还不具备条件;未具备条件落地的差距和原因是什么,梳理还需要做哪些基础建设。
方案给出的落地成果是——“350+规则检测,覆盖ATT&CK框架中60%+的技/战术”。这个数字和前面提到的"550+规则"略有差异（可能是不同统计口径,比如350+是纯粹按ATT&CK框架映射的规则,550+是包含其他类型检测规则的总量),但都说明检测能力已经形成了系统性的覆盖,而不是碰运气式的零散规则堆砌。
这套"找方向—落地—摸底"的三步循环,本质上是一个持续迭代的能力建设闭环——不是一次性把ATT&CK矩阵全部覆盖完就算了,而是要按优先级逐步推进,同时不断根据"哪些暂时做不到"的现实差距,倒推需要补的基础建设。
四、真实攻击案例：从钓鱼到内网横向移动的完整链路
这一部分是方案里最有说服力的内容,用三个真实案例展示了攻击者是怎么一步步从社会工程学钓鱼走到内网沦陷的。
攻击链路总览：从钓鱼到失陷再到出局
方案描绘的攻击场景——攻击者利用招聘、跳槽、客诉、商务、合作等场景作为切入点,通过微信、QQ、企业微信、钉钉、IM+、脉脉、boss直聘等渠道接触目标员工。具体的攻击链路是——用户接收包含木马程序的文件,最终执行上线;黑客进一步在内网横向移动,进行信息收集、漏洞攻击、拖数据等,对企业造成更多的风险和损失。
方案给出的三个具体案例——案例一：钓公司HR、案例二：钓商务BD、案例三：钓跳槽员工——某0day！。这三个案例分别对应了HR招聘场景、商务合作场景、员工跳槽场景这三种最容易被攻击者利用的社会工程学入口。特别值得注意的是案例三提到的"某0day"——说明攻击者不仅利用社会工程学,还会结合未公开的漏洞发起攻击,这对企业检测能力的要求更高。
检测思路：向前向后回溯关联分析
方案给出了一套具体的检测逻辑,以"微信接收文件到执行"的场景为例——向后回溯：发现来自于微信的可疑进程,包括process_event（进程事件)、宏文档启动子进程、可执行文件进程启动、压缩文件解压缩、可执行文件直接点击执行；向前分析：监控微信接收的文件后续出现的行为,包括file_download_event（文件下载事件)、file_operation_event（文件操作事件)、其他受监控终端行为、UEBA（用户实体行为分析)、更多关联命中。
这套"向前向后"双向关联分析的思路,解决了一个检测层面的核心问题——单点告警很难判断是不是真实攻击,但把进程链、文件来源、后续行为串起来看,攻击的完整轮廓就清晰了。这也是为什么方案强调要"从微信接收文件"这个起点开始,同时往前追溯进程来源、往后追踪后续行为,而不是孤立地看某一个孤立事件。
实战成效：30起终端钓鱼，最快1分钟发现
方案给出的实际检测效果——“全年发现超过30起终端钓鱼,平均检出时间<30分钟,最快1分钟内发现”，并且明确提到发现了"攻击队的钓鱼"和"黑灰产潜伏在微信群里的钓鱼"两类不同来源的威胁。这组数据说明这套检测体系不仅能发现红队演练时刻意制造的钓鱼场景,也能发现真实存在的、来自黑灰产的日常威胁,证明了检测能力具备实战化的普适性,不是只针对演练场景调优的"应试型"能力。
内网"无感"横向移动：最难检测的高级对抗手法
方案专门讲了一个非常典型的高级对抗场景——“内网无感横向移动”。攻击链路是——攻击队进入内网后,利用账号SSO权限,查阅内部文档系统、代码仓库,进行信息搜集;通过翻阅到的关键系统、代码、账密,进行横向移动;不发起大量的扫描和payload探测,网络流量设备、终端EDR等系统"零"告警;最后被"一击"即中、"无感"出局。
这个场景之所以难检测,恰恰是因为攻击者没有使用传统的扫描器和攻击工具——他们利用的是合法的SSO权限和正常的文档访问操作,这类行为在传统的基于签名或规则的检测系统里根本不会触发任何告警。
方案给出的检测思路是引入UEBA用户/账号行为分析——结合"员工岗位、技术/非技术序列、所属事业部"这类身份属性,建立"行为/访问基线"（登录位置、常用设备、常用时段、常访问站点),然后判断"是否有超出基线的访问行为、是否有超出业务/职能范围的访问行为、是否有检索敏感词、批量下载代码等异常行为"，配合终端/网络行为关联和内网代理/隧道检测。
这套思路的核心转变是——从"检测已知的恶意工具和手段",转向"检测偏离正常行为基线的异常"。当攻击者用的是合法权限、正常操作时,唯一能暴露他们的线索就是"这个行为和这个人平时的行为模式不一样"。这也是为什么UEBA这类基于行为基线的分析方法,对高级对抗场景至关重要。
五、资产&攻击面的管理：三个真实案例暴露资产失控的代价
方案的这一部分聚焦在资产管理上,提出的问题很直接——“资产的范围和边界在哪里？我怎么知道我有哪些资产？我管理的资产范围和边界真的够了吗？资产管理怎么管？谁给我提供信息源？复杂的范围和边界怎么来管？”
方案指出，随着资产范围从域名、IP扩展到私有云、集团分公司,再到账号、AK/SK（公有云、PaaS产品、K8S集群等）、证书,再到公有云、多云环境、多账号环境,再到控股公司、合作机构、供应商,“随着资产范围和边界的扩充,管理的复杂度上升,攻击面不断扩大,传统的管理手段和思路也应该随着升级”。
案例一：影子资产——买了扫描器却扫不到自己的资产
方案给出的场景非常真实——“买了许多乙方扫描器,各种新出漏洞PoC与时俱进,每周甚至每天做漏洞扫描,积极修复各种高危严重漏洞。攻防演练开始,蓝军在内网中发现存在高危漏洞的XXX应用,可直接RCE”。
问题的根源方案讲得很清楚——“过份依赖内部CMDB/ITSM等数据源,忽略了这些数据源本身的数据完整性和数据质量,形成影子资产”。这句话点出了一个非常常见的误区——企业以为自己的资产台账（CMDB）是准确的,但实际上台账本身就有遗漏,靠这份不完整的台账去做安全扫描,自然扫不到那些"没登记在册"的资产。
方案给出的解法是"构建信安自己的资产发现能力和资产数据库"，具体方式包括主动探测、扫描,以及从更多数据源中被动识别和发现——指纹可以应用到更广阔的范围,比如从流量中识别、从DNS解析记录中识别、从TLS SNI中识别、从HIDS数据中识别、从API数据中识别等。
这套思路的关键转变是——安全团队不能只依赖业务或IT部门提供的资产清单,而要建立自己独立的资产发现能力,通过多种被动和主动的技术手段,交叉验证出真实的资产全貌。
案例二：控股公司域名——脱离集团管控的独立资产
方案给出的场景——“某控股公司有独立域名xxx.org,域名归属于控股公司,Web站点、服务器资源均独立于集团环境之外,由供应商自行部署和维护（或者由集团业务BU对接维护）”。
风险点方案讲得很直接——“由于使用独立域名、环境、云账号,脱离集团SRE的管控,更加脱离信安的管控,依然存在监管、法律、安全、合规等风险”。这个案例揭示了大型集团常见的管理盲区——下属公司或业务单元为了独立结算、快速上线等原因,绕开集团统一的基础设施使用独立资源,结果这部分资产完全脱离了集团安全团队的视线。
案例三：失控的云账号——业务部门自己注册的"黑户"
方案给出的场景——“某业务BU因各种原因（独立结算/新业务尝试/功能尝鲜/历史原因等）,使用了BU的甚至是个人自己注册的云账号”。这个场景比案例二更极端——不仅是脱离集团管控的独立域名,甚至连云账号本身都是员工个人注册的,这意味着这部分云资源的归属、权限、生命周期管理完全处于失控状态,一旦相关员工离职或者账号密码泄露,风险敞口极大。
治理思路：充分设计规范流程 + 收缩边界查漏补缺
针对上述三类问题,方案给出了两条并行的治理路径。
充分设计、规范流程：建立相应的管理流程（如采购/审计/发布/运维等),统一纳管域名、IP、云账号、证书等资源;联合运维/网络/框架/业务/云厂商等各方,充分做好公有云环境的顶层设计,充分考虑安全设计和实现;确保流程及实施过程的统一管理、自动化、不可篡改,确保基线实施、账号/AK/SK等生命周期管理如预期进行;对供应商进行安全与合规评估,建立供应商准入标准和流程。
收缩边界、查漏补缺：联合业务、运维和云厂商,推动存量独立资产的统一接管及整改;对接企查查/天眼查等信息查询,通过工商主体、持控股和投资信息、域名备案等信息,监控和识别疏漏。
方案还给出了一个非常具体的架构改造示意——从"业务员工/供应商/BU技术各自独立注册域名、独立开发部署运营"的混乱状态,改造为"BU资源统一纳入管理"的规范状态——业务需求先经过CMDB登记、由CIS（可能指集中信息安全或类似统一管控团队）交付,SRE统一配置域名指向信息,形成"资源需求→CMDB→SRE配置域名→CIS交付→BU业务/技术使用→内部发布管理流程"的完整闭环。方案还提到了具体的技术实现路径——AWS Landing Zone架构设计（AWS Organization）用于云账户组织化管理,以及基于Terraform的多云服务提供商运维管理用于实现基础设施即代码（IaC）的统一化管控。
这套治理思路的核心逻辑是——先把散落在各处的独立资产统一收编到集团管控体系下,再用工商信息查询这类外部数据源持续监控是否还有遗漏的资产在暗处游离。这两条路径一个治标（发现遗漏)一个治本（规范流程杜绝新增),形成了完整的资产治理闭环。
六、常态化&有效运营：怎么在海量告警里保证响应速度和准确性
这是方案的最后一个核心技术章节,讨论的是安全运营团队每天都要面对的现实难题——“规则和策略越加越多,检测能力提升的同时,告警量也跟随上升,告警事件数量越来越多”，进而带来两个关键问题——“如何保证MTTR（平均修复时间）？检测发现很快,处理和响应速度能否跟上？如何保证准确性？受个人主观判断和知识经验局限,响应处理是否正确？如何减少误判？”
告警聚合：从碎片化事件到高度聚合的完整画像
方案给出的解法核心是"安全事件告警：从事件和信息的维度上应该是丰富的且高度聚合的"，并用一个非常具体的还原案例说明了这个理念。
方案先展示了没有聚合的碎片化信息——“某个终端endpoint_1检测发现了x行为;某个终端endpoint_1检测发现了y行为;某个终端endpoint_1检测发现了z行为;x/y/z行为的父进程是abc.exe,父父进程为xxx问题反馈.exe,身份为domain/zhangsan;EDR日志查询显示xxx问题反馈.exe这个进程文件来自于7zFM.exe对xxx问题反馈.rar的解压缩,该压缩包下载来源为chrome.exe;Itdb系统的查询数据显示终端endpoint_1的IP地址是192.168.x.x,当前使用的用户是张三;员工和组织架构的查询信息显示张三是来自某业务BU的客服专员”。
这些信息如果分散呈现,分析人员需要一个个查询、一个个拼接,非常低效。方案给出的聚合后呈现方式是——“终端endpoint_1上检测发现了x行为,同时发现了y行为,又发现了z行为,进程链为[xxx问题反馈.exe -> abc.exe -> x/y/z],进程身份是domain/zhangsan,该进程文件来自于chrome下载的压缩包,终端endpoint_1的IP地址是192.168.x.x,当前用户是某业务BU的客服专员,名字叫张三”，最终提炼成一句高度浓缩的标签——“客服专员 外部渠道 压缩包 进程触发高危/敏感行为”。
方案总结的原则是——“提供尽可能多的信息,如受影响资产的基本属性、风险行为进程链、来源渠道、做了什么事情、资产owner/用户等,这些信息将有助于快速研判告警事件”，同时"按照主体进行聚合,提高运营专注度,提供更全面的视角"。
这套聚合方法论解决的核心问题是——分析人员看到的不应该是三条孤立的技术日志,而应该是一个完整的、带业务背景的攻击画像。当告警信息里直接标注了"客服专员"“外部渠道”"压缩包"这些业务化的标签,分析人员几秒钟内就能判断这是一起需要重点关注的社会工程学攻击,而不需要再花十分钟去交叉查询各个系统拼凑上下文。
联动阻断能力：多维度多手段，常态化推行
方案给出的第二个运营效率解法是"联动阻断能力：多维度多种手段,常态推行"。具体维度包括——IP地址、Mac地址、域名、账号、权限、文件等,需要不同维度的可控制能力;可以调用的处置手段包括防火墙、交换机、IPS、行为管理、EDR、网关等,不同渠道和手段都可以提供响应处置能力;核心要求是"衔接告警和通知,及时的响应处置,常态化执行"。
这套设计说明——检测出问题只是第一步,真正决定运营效率的是发现问题之后能不能立刻联动多种设备做出响应（比如立刻封禁某个IP、冻结某个账号、隔离某台终端),而不是靠人工挨个登录不同的安全设备手动操作。方案强调的"常态推行"，意味着这套联动阻断机制不能是演练期间才启用的临时机制,而应该是日常运营中随时可用的标准动作。
七、总结：五个方面拼成的常态化闭环
方案在最后用一张总结图,把前面讲的所有内容收拢成五个核心能力方面,并各配了一句提炼——
特定场景、高级对抗手段——对应"针对性方案,数据分析挖掘"。
入侵检测能力——对应"持续迭代、优化,跟随攻击技术和手段的演进"。
资产发现和管理——对应"从制度和流程上设计"。
云资产和三方资产管理——对应"掌握发现能力,灵活应用多种手段"。
做有效的安全运营——对应"收敛聚合、关联分析、自动化"。
这五个方面共同指向中心的一个词——“常态化”。这个收尾结构很清晰地呼应了方案开篇提出的核心主张——安全体系和能力,必须是常态化运行的,而不是演练期间的应急表演。
八、这份方案值得学习的地方
1. 用真实运营数据（20w+告警、73.5%自动化处置）证明常态化体系确实在运转
很多安全方案容易停留在"我们建了一套体系"的概念层面,这份方案用具体的规则数量、告警量、自动化处置率、真实风险发现数、0day捕获数,证明了这套体系是真实运转并产出价值的,不是纸上谈兵。
2. 用ATT&CK矩阵作为检测能力建设的"地图"，提供了系统化的建设路径
不是碰运气式地堆规则,而是先用ATT&CK矩阵盘点全局,按风险优先级排序,再逐个技术点评估能否落地,这套方法论让检测能力建设变得可规划、可衡量。
3. 用三个真实钓鱼案例和内网无感横向移动案例，展示了攻击链路的真实复杂度
从招聘/商务/跳槽三种社会工程学切入点,到向前向后关联分析的检测思路,到UEBA行为基线检测无感横向移动,这些案例的真实性和技术细节远超一般的概念性介绍。
4. 影子资产、控股公司域名、失控云账号三个案例精准命中了资产管理最常见的盲区
这三个案例几乎覆盖了大型企业资产管理最容易出问题的场景——CMDB数据不完整导致的影子资产、下属公司脱离集团管控的独立域名、业务部门自行注册的失控云账号，每一个都配有具体的治理方案。
5. 告警聚合的具体案例展示了怎么把碎片化技术日志转化为业务化的攻击画像
从三条孤立的进程事件日志,到"客服专员 外部渠道 压缩包 进程触发高危行为"这样一句话的浓缩标签,这个转化过程直接决定了安全运营团队的响应效率。
九、给正在建设企业安全运营体系的团队几点建议
1. 不要把攻防演练当成安全建设的终点，而要当成体系运转的一次抽查
参照方案的核心主张,把常态化运营能力建设作为日常工作的主线,攻防演练只是检验这套体系是否真的在正常工作。
2. 用ATT&CK矩阵盘点检测能力覆盖度，按风险优先级排序推进
不要试图一次性覆盖所有技战术点,先聚焦凭证访问、执行、持久化、权限提升这类高风险战术,再逐步扩展覆盖面。
3. 检测规则设计要覆盖"已知恶意工具"和"异常行为基线"两条线
传统的签名规则能抓住已知的攻击工具和手段,但面对不发起扫描、利用合法权限的高级对抗,必须依靠UEBA这类基于行为基线的异常检测能力。
4. 资产管理不能只依赖内部CMDB，要建立独立的资产发现能力
参照方案提到的多种被动识别方式（流量、DNS、TLS SNI、HIDS、API数据),结合主动扫描,交叉验证出真实的资产全貌,避免影子资产长期潜伏。
5. 建立资产纳管的规范流程，同时用外部数据源持续巡查遗漏资产
对内建立采购/审计/发布/运维的统一管理流程,对外借助企查查/天眼查等工商信息查询手段,持续发现脱离集团管控的独立资产。
6. 告警设计要做到高度聚合，让分析人员一眼看懂业务背景而不是拼凑技术日志
参照方案的聚合案例,把资产属性、进程链、来源渠道、用户身份等信息整合成一句话的业务化标签,大幅提升告警研判效率。
结语：常态化安全运营的终点，是让防守体系真正做到"全年在线"
这份《常态化攻防及运营体系建设方案》讲的核心逻辑其实很朴素——安全体系的价值不在于攻防演练那几天表现得多好看,而在于全年365天,面对真实存在的黑灰产、黑客、APT威胁时,能不能持续、稳定、高效地发现问题并做出响应。从ATT&CK矩阵指导的检测能力建设,到真实钓鱼和内网横向移动案例揭示的攻击链路,到影子资产、控股公司域名、失控云账号三个资产管理盲区的治理,再到告警聚合和联动阻断解决的运营效率问题,每一层设计都在回答同一个问题——企业的安全防线,怎么才能从"演练期间临时搭建的应急工事",变成"日常运转的常态化体系"。
对任何正在推进企业安全运营体系建设的团队来说,这份方案最值得借鉴的不是某个具体的检测规则或工具选型,而是它贯穿始终的方法论——用系统化的框架（ATT&CK）规划检测能力建设优先级,用真实案例暴露资产管理和检测能力的现实盲区,用告警聚合和联动阻断解决规模化运营的效率瓶颈,最终目标是让安全能力常态化在线,而不是只在演练期间"临时应考"。这套逻辑,比任何单一的安全产品部署方案都更值得深入理解和复制推广。
以下为方案部分截图：
评论前必须登录！
注册