以功促防 攻防演练对企业价值-全面提升企业安全性

实战攻防演练的结束也是红队改进防守工作的开始。在每次红蓝 对抗演练结束后，应对各阶段进行充分、全面的复盘分析，提出整改 措施。一般须遵循“遗留最小风险”和“问题相对清零”的原则持续 优化防守策略，对不足之处进行整改，进而逐步提升防守水平。因 此，红队可通过沙盘推演、桌面推演等方式找出自己在备战阶段、临 战阶段、实战阶段存在的纰漏，涉及以下方面：工作方案、组织管 理、工作启动会、系统资产梳理、安全自查及优化、基础安全监测与 防护设备的部署、安全意识、应急预案、注意事项、队伍协同、情报 共享和使用、反制战术、防守作战指挥策略等。同时，结合实战攻防 对抗过程中发现的网络架构、主机安全、数据库安全、应用安全、安 全和网络设备、身份安全、供应链等方面的风险和问题进行整改，输 出管理、技术、运维三方面问题的整改措施和计划，实现风险和问题 闭环清零。

复盘总结

本节主要阐述红队防守工作活动的关键复盘动作，复盘动作将分 为管理动作和技术动作两方面。另外，总体复盘任务包括但不限于以 下关键动作，防守单位在复盘工作开展时可以增加总结动作。

（1）设定防守工作目标

结合防守单位自身网络安全的实际情况，设定符合单位防守实际 的工作目标，目标不应过高也不应过低。目标过高，意味着防守工作 投入过大；目标过低，则无法通过演练检验实际的网络安全短板具体 在哪里。所以，应该复盘是否结合了单位网络安全建设的实际水平设 定工作目标。演练活动结束后，检验是否达到预期目标。达到或未达 到预期目标都需要总结，并反思为什么能达到或未达到，即需对目标 结果完成复盘分析。

（2）制订工作方案

复盘工作方案，根据整体防守实施过程分析方案的完备性，以实 际工作过程检验制订的方案中是否存在缺失项。

（3）组织架构和分组职责

复盘是否成立了有足够推动力、可以实现跨部门统筹和协调工作 的领导小组，防守工作小组结构是否健全、完备，各小组职责是否清 晰、完备。分析防守过程中是否存在因职责不明确或组织架构不全， 导致无法感知攻击行为或感知攻击行为后无法及时处置的问题。

（4）防守靶标系统基本信息调研

应该复盘演练前是否对靶标系统的基本信息进行过调研，选择靶 标系统时是否遵循了选择原则，是否调研过靶标系统部署的网络环 境、主机操作系统类型、中间件类型、数据库类型、应用系统开发语 言和开发框架信息，以及靶标系统网络访问策略情况、业务交互情 况、攻击靶标系统的关键攻击路径和运维管理节点是否可控等。

（5）防守单位和人员确认

复盘是否制作了完整的防守单位和人员排班表，是否制作了工作 人员技术能力画像表，技术人员所在的技术岗位职责是否清晰，所在 岗位人员能力是否满足岗位要求等。

（6）工作启动会

复盘防守过程中是否正式召开了工作启动会，是否有具备足够推 动力的领导参加启动会，是否所有相关的防守单位均参加了启动会。

（7）签署保密协议

复盘是否所有第三方参演单位的工作人员都签署了保密协议。参 与工作人员不仅包含实际参战的技术人员，还包括商务、会务和后勤 保障等成员。即使所有工作人员都签署了保密协议，还是需要在启动 会中全员宣贯和强调安全保密的意识。

（8）沟通软件部署

复盘演练活动中是否部署了高效的沟通软件，沟通组织的各个工 作小组人员是否熟练使用软件功能，复盘有没有需要改进的通信组织 结构和账号权限建议。高效的沟通机制是红队防守成功的前提。

（9）防守工作场地

按照各单位攻防演练活动中红队实际参演人数的规模大小，复盘 是否准备了适当的工作场地。一般红队防守工作将持续1～2周甚至更 长时间，因此需要根据防守人数考虑工作场地面积大小、物资保障物 品多少和保障物质的输送频率。此外，还需考虑场地是否需要屏幕， 网络、防守终端设备是否通畅，桌椅板凳是否齐全、舒适等。

（10）制订应急预案和流程

复盘红队防守工作方案中是否包含安全应急预案，检查前期预案 是否包含不同场景，并按照场景设计了符合单位实际的应急处置流 程。

（11）防守规则调研

检查攻防演练活动中红队防守工作的备战阶段，项目组是否充分 了解防守规则，是否对防守规则进行过研讨并制订了规则解读表。

（12）系统资产梳理

复查资产及台账管理，检查防守过程中是否存在由硬件、软件、 数据资产梳理不清或者台账不全、不准确导致资产受损无感知甚至对 遭受的攻击行为无法分析等问题。

（13）部署基础设备

复查防守工作中的基础设备部署方式是否正确，是否存在由部署 位置错误导致设备功能无效或不能发挥全部防护功能的问题。例如， 流量接入不全导致无法实现流量全面监测，服务器加固设备部署的点 不全导致主机防护缺失等。

（14）网络架构

复查整体网络架构的网与网之间是否缺少隔离措施、有没有划分 安全域、是否缺少必要的安全防护设备，是否存在网络设备较老导致 无法升级补丁的情况，在关键网络边界是否具备对抗互联网安全威胁 和网络攻击（抗拒绝服务攻击、入侵防御、恶意代码防护、垃圾邮件 防护、网络访问和流量控制等）的能力。

（15）主机安全

复查是否建立了完整的主机台账，主机操作系统是否还存在多年 前的老漏洞未修复，是否还存在弱口令或统一口令，远程管理是否缺 少安全措施，日志是否缺乏保护和备份（如果缺少，会导致发生安全 事件后无法通过日志进行溯源分析）。

（16）数据库安全

复查是否为数据库建立了快速且行之有效的补丁升级流程，是否 存在弱口令或者默认口令，数据库访问是否没有权限控制，以及数据 库的软件安装权限是否过大（如采用root权限安装）等。

（17）应用安全

复查防守工作中是否记录了所有被攻击应用系统的攻击路径，对 于攻击发现的各类漏洞（注入、越权、XSS、逻辑漏洞等）、采用的组 件（如开源组件）、中间件、安全配置不规范（例如配置信息中包含 敏感的数据库信息、允许弱口令、后台暴露等）、部署不规范（例如 部署人员在升级时覆盖了之前已修复的补丁，导致旧的漏洞重现却不 知道）等是否进行了漏洞台账管理和修复与加固。

（18）安全和网络设备

复查安全设备、网络设备在攻防对抗中是否对发现的新漏洞 （0day或Nday）进行了修复，是否存在以下情况：安全策略配置过粗 （如：怕影响业务，WAF禁止使用太多的策略；为了运维方便，网络 ACL直接按段开放），策略有效性未经检验（无人检验配置是否生效， 实际并未生效），策略冲突（较严格的控制策略被较粗的控制策略覆 盖），配置问题（存在弱口令或默认口令，访问不受限制，特征库升 级迟缓，授权过期），等等。这些问题会给单位的安全运营、运维工 作带来较为严重的风险。

（19）身份安全

复查是否所有的设备、应用都有身份鉴别功能，身份鉴别功能是 否完善，权限划分是否合理，同时复查使用设备、应用的人员身份是 否存在认证和权限过大的问题。

（20）安全自查及优化

复查防守过程中的安全自查及优化方式、手段是否足够，发现的 问题是否均已整改，整改是否存在遗留问题，并评价整改措施是否有 效。

（21）注意事项

复查防守工作中是否向全员提示了完备的注意事项，是否还有可 以补充的注意事项，原有事项描述及要求是否合理等。

（22）应急演练

复查防守工作中是否存在新的突发应急事件在原应急预案中没有 涉及，预案设计是否合理、全面，应急演练过程、阶段是否缺失，预 案设计与实际的应急处置是否匹配，是否存在纸面设计与实际工作脱 节的问题等。

（23）安全意识培训

复查安全意识培训方式是否有效，培训对象是否有缺失，培训内 容是否完备，培训频度是否足够高等。

（24）红队防守期间每日常规动作

复盘红队防守期间所有干系人的常规动作是否按照工作分组进行 标准化。常规动作不仅包含技术人员的技术操作，还包含总结和梳理 演练活动中的管理行为、后勤保障行为等。

（25）队伍协同

复查防守工作中各个参演部门和第三方支持厂商是否履行了规定 的相关职责，各个节点在工作配合过程中是否有效执行了工作职责内 容，不同位置上各司其职的工作人员是否进行了协同、使队伍，高效 运转等。如发生了协同配合不顺畅的问题，检查是否找出了问题原因 和解决方案。

（26）防守作战指挥策略

复查是否总结了对抗期间的总体指挥防守策略，在不同的攻击场 景下是否有不同的指挥应对手段等。

（27）攻击队攻击方式总结

1）互联网突破总结。复盘红队是否提前研究了互联网突破的攻击 方式，是否针对各类突破方式解读被攻击时的监测行为和流量监测告 警提示状态，是否制订了发生攻击和产生告警提示状态时的管理和技 术应对举措，是否将此防御技术编入防守技战法手册并定期维护。

2）旁站攻击总结。复盘红队是否提前研究了旁站攻击的突破方 式，是否针对各类旁站攻击方式解读被攻击时的监测行为和流量监测 告警提示状态，是否制订了发生攻击和产生告警提示状态时的管理和

技术应对举措，是否将此防御技术编入防守技战法手册并定期维护。

3）传统渗透攻击总结。复盘红队是否提前研究了攻击队经常使用 的传统渗透攻击方式（如经常使用的WebLoigc反序列化命令执行攻 击、JBoss远程代码执行攻击、Struts2远程命令执行攻击、Redis未授 权访问攻击、永恒之蓝漏洞攻击、Windows操作系统漏洞攻击、数据库 弱口令和操作系统弱口令攻击、FTP匿名登录攻击、rsync未授权访问 攻击、HTTP OPTIONS方法攻击、SSL/TLS存在Bar Mitzvah Attack漏洞 攻击、X-Forwarded-For伪造攻击等），是否针对各类突破方式解读被 攻击时的监测行为和流量监测告警提示状态，是否制订了发生攻击和 产生告警提示状态时的管理和技术应对举措，是否将此防御技术编入 防守技战法手册并定期维护。

4）物理攻击总结。复盘红队是否提前研究了物理攻击的攻击方 式，是否针对物理攻击类型制订了管理和技术应对举措，是否将此防 御技术编入防守技战法手册并定期维护。

5）利用大型内网做跨区域攻击总结。复盘红队是否提前研究了攻 击队利用大型内网做跨区域攻击的方式，是否针对各类跨区域攻击方 式部署了监控设备，是否解读了被攻击时的监测行为和流量监测告警 提示状态，是否制订了发生攻击和产生告警提示状态时的管理和技术 应对举措，是否将此防御技术编入防守技战法手册并定期维护。

6）集权类设备或系统攻击总结。复盘红队是否提前研究了集权类 设备或系统的攻击方式，检查攻防演练活动的防守备战阶段是否对集 权类设备和系统进行了安全加固，在监控系统中是否针对集权类设备 和系统制定了定制化监测规则和策略，是否解读了集权类设备和系统 被攻击时的流量监测告警提示状态，是否制订了发生攻击和产生告警 提示状态时的管理和技术应对举措，是否将此防御技术编入防守技战 法手册并定期维护。

7）专挖0day+1day总结。复盘红队是否提前研究了0day+1day漏洞 攻击方式，是否针对此类漏洞攻击方式解读被攻击时的监测行为和流 量提示状态，是否安排专人定期对重要设备和系统读取日志、新增进 程、新增文件巡检，是否制订了发生攻击和产生流量提示状态时的管 理和技术应对举措，是否将此防御技术编入防守技战法手册并定期维 护。

8）供应链攻击总结。复查是否建立了供应链厂商、产品清单台 账，是否制定了供应商安全维护管理规范并禁掉或最小化供应商远程 维护系统的管理权限，是否有本地维护的未经许可自带设备接入内 网，是否对供应链企业清单进行自查（包括但不限于产品品类、开发 商名称、开发商资本结构、产品名称、主程序名与安装路径、版本 号、是否OEM、软件开发规范、软件工程规范、开发语言、运行环境、 涉及的操作系统、涉及的开源项目、版本控制系统、已知系统漏洞、 是否有信息传回开发商、回传信息及位置、授权模式、开发环境代码 审查机制、开发环境漏洞扫描机制等）。

9）邮箱系统攻击（获取信息）总结。复盘红队是否提前研究了邮 箱系统攻击方式，是否针对邮箱系统突破方式解读被攻击时的监测行 为和流量监测告警提示状态，是否制订了发生攻击和产生告警提示状 态时的管理和技术应对举措，是否将此防御技术编入防守技战法手册 并定期维护。

10）免杀、加密隧道等隐蔽攻击总结。复盘红队是否提前研究了 免杀和加密隧道等隐蔽攻击方式，是否针对此类隐蔽攻击方式解读被 攻击时的监测行为和流量监测告警提示状态，是否制订了发生攻击和 产生告警提示状态时的管理和技术应对举措，是否将此防御技术编入 防守技战法手册并定期维护。

11）钓鱼、水坑，利用人的弱点总结。复盘红队是否提前研究了 钓鱼和水坑攻击方式，是否对全员进行了安全意识宣贯培训，是否针 对钓鱼、水坑的攻击方式解读被攻击时的监测攻击行为和流量监测告

警提示状态，是否制订了发生攻击和产生告警提示状态时的管理和技 术应对举措，是否将此防御技术编入防守技战法手册并定期维护。

12）目标单位周边Wi-Fi攻击总结。复盘红队是否提前研究了Wi- Fi攻击方法，是否解读了此类攻击发生时的行为和流量提示状态，是 否制订了发生攻击和产生提示流量状态时的管理和技术应对举措，是 否将此防御技术编入防守技战法手册并定期维护。

13）业务链单位攻击。复盘是否梳理了业务链资产清单，是否在 此类业务链交互出口部署了监控设备和系统，是否制订了业务链单位 发生安全攻击时的应急预案。

14）安全产品、IoT设备等漏洞利用。复盘是否梳理了IoT类业务 设备系统资产清单，是否制订了此类设备发生安全攻击时的应急预 案。

（28）情报共享和使用

复查所有生产威胁情报的小组是否形成共享网络，是否在职责范 围内进行了情报管理工作，上下级单位和同行业单位之间是否在使用 威胁情报的同时也共享其他单位的威胁情报信息。收到共享的威胁情 报，是否导入了安全监测设备，并结合威胁情报对网络中的流量进行 查询和分析，以精准发现已发生攻击行为或潜在攻击行为等。

（29）反制战术

如果防守工作中使用了反制战术，复查是否对反制战术进行了总 结并形成方案，为以后防守提供支持。

（30）攻防演练总结

复盘红队在攻防演练过程中是否提交了所有技术报告，攻防演练 结束后是否对防守成果、防守心得、技战法进行了总结汇报，组织方 是否召开了防守复盘会来总结经验教训和制订问题整改工作计划。

改进措施

针对在复盘总结中发现的问题和薄弱点进行梳理与分析，制订下 一步工作计划并给出解决问题的措施和手段，确定近期可解决的问 题、需要长期增加安全措施和优化工作机制才能逐步解决的问题，从 管理、技术、运维3个层面确定需要完善和优化的安全措施和手段，并 将优化机制、措施加入日常的安全运营中。

在此，我们将重点介绍应用系统安全运营管理，而不会详细介绍 网络安全强调的安全建设和安全规划的概念与方法。在应用系统安全 运营管理方面，建议红队防守单位至少逐步形成并完善以下机制、措 施和安全运营管理。

（1）应用系统生命周期管理

一个应用系统一般会经历需求、设计、开发、上线运行和下线5个 阶段。在以往的信息系统开发过程中，单位重点关注的是能否按照业 务需求按时完成系统功能开发，按时上线并运行。事实证明，在上线 后才开始关注应用系统的安全问题已被证明并不是有效的安全解决方 式，而且软件的安全问题中很大一部分是由不安全的设计引入的。

经过分析和对比发现，凡是在设计阶段就将安全工作纳入开发工 作中并在后续的各个阶段都能够贯彻执行的应用系统，在运行后出现 的安全问题相对较少，整改起来也相对容易和彻底。因此建议单位在 安全运营工作中重视应用系统的生命周期管理。

1）应用系统开发安全管理机制。除了正常的应用系统开发管理工 作外，还应关注开发安全管理工作。对此，建议在设计阶段引入安全 管理机制，让安全专家对设计方案进行审核和评审，提出安全建议， 以提高应用系统在设计阶段的安全健壮性。具体可从如下几方面开展 工作。

• 在应用系统立项时就初步明确该应用系统的安全等级，以确保 后续安全设计工作有一定的依据。

• 在应用系统需求调研时，对需求调研人员进行应用系统安全开 发规范培训（应提前制定应用系统安全开发规范），在形成需求规格 文件后，组织需求规格安全评审。

• 在应用系统设计阶段，主要完成对应用系统设计方案的评审。

• 在应用系统开发阶段，对开发人员、测试人员进行应用系统安 全开发规范培训（应提前制定应用系统安全开发规范），使得开发过 程安全可控。

2）应用系统上线安全管控机制。单位应该建立健全的应用系统安 全上线前的检测流程、标准和制度，安全负责部门应严格执行应用系 统上线前的安全检测工作，包括应用系统安全扫描、基于业务流程的 渗透测试、代码审计和安全配置核查等。待应用系统通过安全评估后 才能允许其进入上线运行阶段，禁止让带“病”的应用系统上线运 行。

受人力物力的局限，单位一般很难完全通过自身开展该项工作， 因此建议单位聘请专业的第三方安全公司或者机构来专门负责应用系 统上线前的安全检测和评估工作，以保证评估结果的客观性。

3）应用系统运行安全管控机制。应用系统在运行过程中的安全问 题主要表现在：各类漏洞的暴露（操作系统漏洞、应用系统漏洞、数 据库漏洞等）、应用配置不当（后台暴露、Web弱口令、敏感信息泄

露、目录权限设置不当等）、升级部署不规范（升级导致之前的漏洞 补丁被覆盖，升级之前未备份数据导致数据丢失等）。

关注应用系统在运行过程中的安全，建议：采用主动防御理念， 通过部署WAF、网站云防护、网页防篡改等安全设备，提高应用系统在 运行过程中的边界防护能力；通过定期进行漏洞扫描、渗透测试、安 全检查与评估等，及时发现应用系统在运行中存在的安全隐患；建立 起应急处置机制，以快速对发现的应用系统问题进行整改。这样，通

过建立起防护、检测和处置的闭环运行管理机制，提升应用系统动态 安全防护能力。

4）应用系统下线安全管控机制。在安全运营中，应用系统下线相 对简单，但也存在容易忽略的风险。例如：只关闭系统域名，但服 务、服务器却还在运行；下线后各类数据丢在一旁不管，导致数据泄 露风险提升；下线过程没有对应的流程，导致系统下线过程没有相应 的记录等。

针对上述问题，建议在日常安全运营中，无论应用系统是正常下 线还是因安全问题下线，都应该遵照既定的流程进行。在应用系统下 线前，应完成应用系统数据备份、数据清除、资源回收和设备回收等 工作，同时应检查以确保应用系统下线后不存在遗漏情况，避免出现 应用域名停用而服务还在运行的情况。最后，还应在资产台账中同步 更新相关信息，完善应用系统下线后的安全措施。

5）其他关键点管理措施。应用系统生命周期管理工作主要体现在 上述4个环节。为了更好地开展应用系统生命周期管理工作，我们根据 多个项目的经验梳理了关键点，主要涉及在新应用系统上线前如何开 展安全检测工作、如何开展漏洞管理工作两方面。

漏洞管理工作稍后介绍，这里来看应用系统上线前安全检测。在 日常安全运营中，有的单位在新应用系统上线前开展过安全检测工 作，有的单位并没有。我们根据多个项目的经验，梳理出系统上线前 开展安全检测工作的关键点，以供单位参考。主要关键点如下。

• 单位日常安全运营中，应建立新系统上线安全检测管理制度和 流程，对上线系统进行“体检”。

• 如果系统属于在建项目，有条件的话，可以将总集成、监理、 开发单位、业务部门及安全部门全部纳入上线前检测审核中，通过各 方监督，保证该项工作按要求完成。

• 如果系统属于内部自建项目，可以将业务部门、开发部门、安 全部门等主要部门纳入上线前检测审核中，通过各方监督，保证该项 目工作按要求完成。

• 系统上线前是否需要经过安全检测，应该由参与部门根据系统 实际情况（一般看系统变更情况）进行审核和确定。

• 安全检测（主要从安全扫描、代码审计、基于业务流程的渗透 测试、安全评估等方面开展）完成后，应出具详细的安全检测报告， 并与各部门负责人同步。

• 开发部门（或单位）应按照出具的检测报告开展整改工作，整 改完成后由安全部门负责开展复查工作。

• 复查完成后，安全部门召集各部门汇报整改情况。若整改复查 符合要求，则各方签字，进入上线阶段；若整改复查还存在不符合要 求，则继续进行整改，直至整改复查结果符合安全要求为止。

通过上线前安全检测，减少新上线系统的安全漏洞，从而减少新 系统上线后给业务带来的安全风险。

参考资料

红蓝攻防构建实战化网络安全防御体系
青藤云安全 2022攻防演练蓝队防守指南