进入10月份，是各项工作收官的季节，也是开始筹划未来一年工作规划，准备相关预算的季节。作为安全负责人，在预算沟通上面对的挑战、回答的问题，都离不开“安全的尽头是什么”这一终极追问。毕竟对财务部门而言，安全属于成本中心，对安全的投入难以实现成本绩效的考核（ROI），不出事属于沉没成本，出事了属于无效成本，安全事故与安全预算难以建立有效的关联关系。

即使对于主管安全的CIO和CTO而言，对于安全主管提出的纵深防御、异构防御仍不免心生重复建设的疑虑。而层出不穷的安全厂商，在一些点的防御、能力产品的构建以及希望提供一揽子解决方案的野心，也带来安全产品边界的重叠，安全主管在每个领域用最适用场景的产品构建防御体系的时候，不得不面对这些鸡肋重叠功能描述的困扰，向CIO、CTO解释之余，还增加了选型、部署、以及协作过程中的沟通成本。

如果说在公司风险接受范围内，构建网络安全的防御体系，实现成本效益最优情境下的风险最小化是一个技术活的话，那么如何实现组织范围内对网络空间安全保障达成共识就是一个艺术活。需要安全主管建立分析框架，把最佳实践和思考过程，用组织管理的通用语言在规划阶段回答其他部门和领导的潜在疑问，实现组织的共识。其中的关键在于不同利益诉求方在统一规则下的平衡。

图一、网络空间安全平衡框架

一、目标的平衡

在各类经典的著作和认证课程中，安全的目标需要与组织的战略目标，业务目标保持一致，都是放在最关键的位置。如果没有经过系统的训练，或在组织中有过类似论证的过程，确实容易被忽略或忽视。

知易行难，把理论转换为实践，对安全主管而言也并非易事。了解组织的战略以及业务，对很多安全主管而言，需要逾越业务的挑战。这个目标并不是纸面上的财务指标，也不是会议上的宣传指标，而是业务发展过程中的关键支撑环节。

在信息化甚至数字化背景下，关注的是自动化的运作流程和业务人员的运营模式，其中的挑战在于，安全主管或安全团队成员需要真正懂业务、懂系统。如果安全团队仅把自己定位为信息化基础设施的安全保障者，认为无论什么业务，我所做的都是为你提供一个安全的环境，那么其实就已经和业务团队貌合神离，互不待见了。安全团队不考虑业务团队的情景和目标，业务团队也不会考虑安全团队的目标与需求，安全工作的落地和推进寸步难行也在所难免。

在数据安全和个人隐私保护中有个环节叫做PIA（个人信息影响分析），安全团队在分析公司战略目标和业务目标时可以借鉴，简称为CIA（网络空间安全影响分析）。主要目的是了解公司整体的战略目标和业务分布的轻重缓急，根据业务分析业务运作模式在数字化技术体系下的框架和结构，分析可能面对的威胁、存在的脆弱性，根据业务的规模、投入产出，估算风险的可能性以及最佳的成本配置，找到平衡的目标框架。

这个环节相对于风险评估而言，关注的不是定量的技术漏洞相关的分析，而是从定性的角度，估算整体的影响以及网络空间安全的定位和投入量级。这个环节中尤为重要的是跳出技术基础设施保障的传统思维，寻找到业务场景中安全助力业务发展的独特优势，找到亮点，与业务形成共鸣，也是业务安全的关键目标，真正是围绕着业务目标实现网络空间安全。

从业务出发的平衡考量，助力业务发展的业务安全亮点，可以与业务、公司层面快速达成目标的共识。网络安全目标是公司整体战略目标和业务目标的有机整体，不可分割的一部分，一旦形成这种共识，后续的安全工作开展就很少在具体执行环节遇到难以逾越的挑战。很多遇到巨大挑战甚至失败的安全团队，主要的原因就在于忽视了目标平衡共识的达成，在执行环节陷入到细节的陷阱中，百嘴莫辩，难以自拔。所以目标的平衡影响最大，平衡成本最低。

二、风险的平衡

风险接受度是所有风险管理领域教科书强调的一个重点，基于风险评估的风险决策，指导风险控制措施的落地实施，在平衡目标下对风险评估结果，给出风险接受度的相关建议，由业务负责人和公司负责人进行风险决策，是实现风险维度平衡的最佳实践。

风险与组织环境、业务环境、技术体系、业务场景密切相关，风险的评估不仅是传统意义上的漏洞评估、漏洞管理，需要对资产安全属性做相应的梳理，以安全为中心建立资产管理体系。这个资产不仅是传统意义上的硬件、软件资产，还应包含数据、组件、接口等具备漏洞特性的虚拟资产。而在资产生命周期的基础上建立动态自动化的风险评估体系，实现实时风险视图，形成风险接受度建议报告，是建立快速决策沟通机制的良好方法。

风险评估也是被很多安全主管和安全团队忽略掉的实践，并不是不做风险评估，而是以漏洞扫描、安全检测和监测代替了风险评估。威胁的发现、漏洞的评级是风险评估之后安全措施的相关成果，不能替代风险评估，基于威胁和漏洞的决策也不等同于风险接受度决策，而是安全团队内部决策的范围。

另外，外部的风险评估和静态的风险评估也容易流于形式，给出的结论难以上升到风险接受度决策，也难以指导安全措施的构建和落实。需要安全主管和安全团队重视风险评估的动态、实时的解决方案，真正做到把风险评估的结果作为与业务部门、上级主管领导沟通风险决策建议的证据，从而形成风险层面的组织共识。

风险的平衡，是建立在安全目标确定前提下的风险接受度决策。安全主管和安全团队要拿出专业的、行之有效的建议，决策权属于业务主管和组织高层管理者，决策的结果就是组织风险接受的范围，也是风险平衡的结果。在这个层面而言，影响范围居中，平衡的成本居中。

三、措施的平衡

在实践中，由于对目标、风险的平衡不足，往往上级领导和业务部门对安全的挑战发生在安全措施的平衡层面。安全措施是在确定目标和风险接受度的前提下，针对需要控制的风险和需要确定的解决方案，包括各种安全措施能力的建设以及持续运营。

安全措施属于专业领域，安全解决方案的细节、安全产品的选型和测试，安全能力的建设和运营，属于安全主管决策的范畴和安全团队专业工作的领域。如果把相关的技术细节、实现原理、目的、功能、必要性跟财务、业务、主管领导沟通清楚，既是个宏大的工程，又是个跨专业领域的挑战，几乎是不可能完成的任务。演变成安全主管与安全团队，说又说不清楚，做又面对挑战和挫折，一旦在这个环节杯葛，往往是决策者拍脑门的决定，安全主管与安全团队铩羽而归，委屈不已。

但并不是说安全措施不做平衡，只不过是平衡的决策需要专业的人做专业的事，由安全主管和安全团队做相应的取舍与平衡。也并不是说安全团队一言堂，不容他人置喙，与研发部门、运维部门（SRE）、业务运营部门、采购部门，就架构、开发、部署、运维、用户体验、商务等方面进行专业的把控必不可少。这个参与度属于平行部门的专业把控，不涉及安全领域的专业评估和评价，是在具体安全产品适用安全措施的平衡。

安全措施进一步细分为解决方案、能力建设、安全运营，解决方案需要参考业界最佳实践，考虑风险控制基础上的成本、效能、性能、易用性等要素，实现最佳投入产出比。能力建设需要根据安全团队的规模、能力的通用性以及市场上的选择空间，可以考虑自建、开源软件构建和商用产品购买。任何解决方案包含的安全产品需要进行过测试和有效性检验，可以证明控制点的场景实践有效性。

安全运营是不容忽视的安全措施落实实践，需要持续检测和监测安全相关的事件，动态调整和优化安全风险的评估，对安全事件进行应急响应和复盘报告，持续优化安全措施，以实现安全措施的动态平衡。

综上所述，网络空间安全如何达到一个平衡状态，在组织决策和执行中实现平衡，需要从三个方面综合考虑。不要陷入安全措施底层细节的纠结，而要从安全目标着手，实现安全目标与组织目标和业务目标的有机整合，这个决策层级属于公司管理层和业务管理层对安全团队目标分析的理解和认知。

在安全平衡目标共识的前提下，以安全团队动态安全风险接受度决策建议为基础，组织管理层和业务管理层实现风险接受度的决策，达成风险平衡的共识。有了安全目标和风险接受度的平衡共识，安全主管和安全团队在平行业务部门专业支撑下，主导安全措施的平衡决策。

在讨论9月主题的时候，社群里两个大佬精彩地对了一副对联：“开源组件漏洞紧急修，修修修，何日是个头，问君如何做，才能枕无忧；安全策略补丁即刻补，补补补，今朝提重议，看汝怎谏言，方可处安泰。”如此一来，就形成了“查缺补漏”的9月主题。

笔者最近几个月一直在关注有效性验证和观测性两件事，发现本质上也是朝着如何实现安全风险以及安全控制措施满足安全目标这个主题探索。在8月份的时候，笔者已经写了两篇关于安全控制有效性验证从技术到产品实战的文章，那么今天不妨从这件事的源头捋一捋——为什么查缺补漏成为重中之重，为什么可观测性以及有效性验证的理念、技术和产品成为当下炙手可热的方向。

沿着开源组件漏洞这件事说起。为什么开源组件作为开发安全难以逾越的屏障，成为软件供应链安全和软件成分分析（SCA）热门的赛道？根源在于互联网和数字化导致的信息系统自主研发，打破了商业产品的研发安全过程管理（SSDLC），在关注持续集成与交付的DevOps浪潮中，开源组件成为信息化系统密不可分的一部分，而忽视了开源组件自身的特征，以及管理措施不到位，造成大量的技术欠债需要整改，翻工。

各种团队怀着各种目的开源自家的软件产品，开源组件已经成为互联网和数字化产业技术能力对外输出，以及技术路线众包和商业产品活跃、打磨、验证的绝佳路径，但这也带来了和商业软件与组件不同的安全风险。

开源组件难以保持持续的活跃度，无论是技术路线还是团队，缺乏约束和管控，极有可能活跃度下降，商业闭源。如果开源组件出现安全风险，及时地修复和升级缺少商业产品的服务水平协议（SLA）保障，有可能都无法单纯地从版本升级的角度进行升级。另外，如果企业缺少开源组件引入的评估、审核、使用控制机制，可能出现多研发团队采用多版本组件，自定义二开开源组件的问题，在发现开源组件漏洞时，造成即使开源组件升级新版本，仍难以直接升级和体系化升级的问题。第三，由于开源组件的丰富性，SCA安全厂商仅能针对威胁情报和扫描工具做漏洞的检测工作，难以实现POC验证以及代码级修复的建议，仅通过第三方漏洞情报的评级机制，忽略了应用场景和过程，评级的客观性遭受研发团队质疑。

这些问题纠结在一起，导致安全团队在发现大量漏洞并推动研发升级的过程中，需要痛苦的沟通、协调和逐个的排查、确定、实施，从而形成了开源组件漏洞修复的长尾工程。

如何有效地实现开源组件的风险管控，根据笔者自己与SCA厂商、业界同仁的沟通交流来看有几个建议。

一是实现可信制品库的管控机制。研发的架构部门要从整体技术体系的角度对开源组件的引入进行评估评价和审核，开源组件的团队、活跃度、技术相关性等可用性与可持续性指标要进行评估评价，纳入可信制品库供研发团队使用，避免随意的开源组件引入，对开源组件的使用建立明确的规则，二开统一进行，避免使用上的随意性。

二是建立开源组件的漏洞验证和代码级修复情报共享机制。无论是SCA厂商，各公共SRC、白帽社区或商业厂商，建立开源组件漏洞的POC与代码级修复情报有偿或无偿共享机制，除了升级修复外，提供代码级修复和补偿控制机制，支持二开开源组件安全升级的兼容性。

从实践的角度而言，开源组件的安全风险治理，第一步是需要明确开源组件的分布范围，包括在代码库哪个工程做了集成，在发布系统哪个应用里有所体现，发布后所在的服务器等。从网络架构和安全控制措施的角度而言，利用的难度和复杂度如何，这些信息如何一目了然地呈现，安全人员可以根据工程、应用、服务器的资产归属人员，找到具体负责人实现快速的任务下达与协调推动。这说起来容易，但却需要建立在准确、有效、多标签的动态资产管理系统的基础之上。

传统的资产管理一般基于CMDB建立的录入静态资产库，面对的挑战是资产收录的完整性，资产频繁变更后资产关键属性的准确性，以及资产生命周期管理的有效性。如果是靠人工录入和扫描数据导入的静态管理方式，准确性、及时性、有效性、可用性就会大打折扣，很容易出现按图索骥时货不对版，责任人不相关等情况，大部分无效的沟通与协调都源自于资产管理的失效。

Gartner在2021年提出的EASM扩展的攻击面管理，强调了关于分支机构、合作伙伴以及新兴虚拟资产方面的用例，而传统的从运维角度关注的数字资产管理容易缺失安全属性的要求。首先是资产的范围，例如我们说的开源组件、工程、应用、API甚至当下热点的数据，都是我们关注的资产。资产之间的关系不是1：n的属性依存关系，而是n：n的多维标签关系，例如，我关心一台服务器上部署的应用、存在的组件，我也关心某一个组件分布在哪些服务器上，集成在哪些应用里，多维度、多视角、多标签是动态资产管理的核心需求。

资产和标签的多元性，如何保障准确性、及时性、有效性，首当其冲的是多源数据，不能仅依赖于手工录入和定期扫描，资产管理的规范与标准以及系统的API接口是实现资产及时性、准确性、有效性校验的前提条件，这条路仍布满荆棘和崎岖，也是我们为什么要关注可观测性的根源所在。

CNCF的云原生对可观测性的定义包含日志、度量与跟踪。日志大家并不陌生，它是数据驱动安全的第一要素，但遗憾的是在数字化时代和互联网场景下，日志其实是个难度比较大的技术活。除了需要关注数据合规与安全的风险之外，日志的粒度会引起存储和分析的指数级增长，如果不做好相应的规划，很可能日志功能仅有1-3天的周期甚至直接关闭，等到我们需要使用的时候，例如去做溯源和取证，才发现可能找不到可用的数据。

另外一个数据驱动安全的要素。大家谈的最多的是流量、全流量，基于核心交换机的分光实现数据全流量的采集和分析，从出口一个维度而言，也无可厚非，也确实起到一定的作用，态势感知、API安全都有应用。当下的问题是在容器云、微服务、零信任的背景下，缺少内部流量的分析与跟踪，仅能对外部的攻击和威胁实现基于出口节点的识别与判断，缺失了内部安全控制的风险威胁发现与预警。

当然，为了解决这个问题，行业内从20多年前SOC开始就尝试建立统一的数据体系，实现风险的发现、预警与响应管理，并且从第一代基于日志，到SIEM时代静态日志到动态流量的整合，再到今天XDR进一步整合了终端、网络的行为特征，实现多源数据的整合。随着数据存储、分析、处理能力的进步以及人工智能领域的机器学习、深度分析等无监督学习算法的崛起，似乎看到了关联分析的曙光，避免基于单点规则对威胁的检测与感知的漏报，甚至实现未知威胁的发现与预警。当然，理想很丰满，现实很骨感，人工智能在多源数据分析的实战价值仍有待考验，有效性仍需要持续的优化和验证。

国外的分析案例往往集中在监控和可观测性区别方面，监控仍是基于点的观察和预警措施，可观测性是基于多点跟踪的关联分析预警措施。但我国更多谈论的是可视化，甚至进一步演化为可视化大屏，通过大屏以动画的形式演示攻击的路线，绚丽多彩，不懂行的领导也看的不亦乐乎，可惜的是往往被安全厂商做成了演示Demo。本质上而言，可视化是结果的可视化而不是链路跟踪与度量层面的可视化；可观测性，是过程的可视化而不是结果的可视化。

回归到开源组件的可观测性，从资产角度可以知道开源组件引入、集成、发布、上线、应用的路径，甚至跟踪到用户业务逻辑过程中开源组件参与的功能和环节，无论从开发和运营的角度，风险都一目了然。

当然，理念如此，实现未必一帆风顺。从云原生的角度而言，互联网和数字化业务基于容器云、微服务，其基础技术架构体系与传统技术栈有较大的变革，传统安全数据的采集能力也面临着较大的调整，是否准备好了并能够实现，是个挑战。

云原生架构下，操作系统的网络栈实现也随着一个开源组件大放异彩。eBPF作为底层的网络技术栈，已经不满足传统的定位，整个开源体系中的cilium、hubbo除了关注底层的处理，替代iptables的4层网络管控策略，已经开始往7层微服务治理的角度去做延伸。在网络底层的数据采集能力，优势是每台服务器、每个容器的全量数据、网络、应用、业务安全实现全覆盖，劣势是海量数据的处理对性能的影响。

在API与微服务层面，enovy的代理lstio的管理数据与业务数据分离，结合Pod的Sidecar模式，提供微服务层的数据全量采集，同样是应用安全、业务安全的数据最佳采集点。

Java的JVM提供的Sandbox模式，实现开发语言运行环境的数量采集，除了实现应用管理（APM），质量和运维风险的跟踪监控外，也可以实现RASP、IAST的应用安全处置，以及数据安全和业务安全的全流量跟踪与采集。

三种技术路径都为数据驱动安全的可观测性提供了数据采集点，采用什么样的技术方案、场景、资源投入、目标密切相关，这也需要安全厂商和具备安全研发团队的大厂进一步探讨、实践和验证，但方向应该是毋庸置疑的。

查漏补缺这件事是安全能力建设到一定阶段，安全运营具备一定水平之后，水到渠成的一个目标，如何做好，当然有无数条路径和值得参考与学习的实践经验。个人而言，和我目前关注的可观测性和有效性验证密切相关。

本文更多的是从开源组件治理，扩展攻击面资产管理，以及云原生技术栈下数据驱动安全的数据采集实现可观测性，这几个具体实践项目的探索给出个人的认知与经验总结陈述，由于有效性8月份已经写过两篇文章，就不再赘述。希望本文能给大家带来些思路和启发，也希望同仁们多交流、碰撞和探讨。

红与蓝：安全控制有效性验证的现状与展望

     文 | 刘志诚

安全体系的建设是个亘古常新的话题，伴随业务需求、技术进步、组织模式不断推陈出新，往深入，细致领域发展。从NIST的IDPRR的构建框架，到安全滑尺从基础体系建设到主动防御的能力提升框架，再到GARTNER推出的IDPR基础上的持续自适应安全架构，都在安全保障能力如何实现纵深防御的铜墙铁壁上下足了功夫。不过，总会有质疑的声音出现：安全能力体系的建设，如何证明真正起到控制风险的作用，可以为业务保驾护航？回答这个问题，就需要从不同角度进行论证。

1、合规建设，满足安全合规的要求，是一种论证模式。

国家对网络安全的重视也经历了计算机时代、网络时代、信息化时代、数字化时代的沿袭变革。在我国网络安全历史上承担重要地位的等保测评机制，通过细化的安全基线检查列表，在信息化安全人才紧缺的时代，为建立企事业单位安全防线立下了汗马功劳，并在2.0的升级版本中涵盖了新兴技术和需求，弥久常新，奠定了网络信息安全基础能力体系建设的基调。当然，基于静态的基线核查模式的检查，缺少实时、动态、持续化、自动化的验证和监测能力，缺失了持续性安全检测的一环。

攻防演练，通过动态、实时的模拟真实攻防场景的验证和检测，在五年来发挥了积极的价值和作用，从第一届的边界保卫战，到第二届的0day大战，再到第三届的社会工程，可以看到安全行业和防守方企事业单位安全攻防能力的持续增长，其中安全产品爆出的漏洞被攻破，更是为整个安全行业自身安全能力建设敲响了警钟。当然，攻防演练过程中也不乏出现停网站、拔网线等令人啼笑皆非的事件。

无论等保检测还是攻防演练，都是国家网络安全主管单位从合规角度出发的整体安全控制有效性验证的手段，从企业的角度而言，仍是合规出发的安全验证。

2、内部审计，满足安全管理体系的要求，是另一种论证模式。

审计，作为公司治理有效性验证的重要手段，在财务领域一直有比较广泛的应用。随着信息化时代的发展，传统四大审计事务所的业务领域也深入到信息化审计中，网络信息安全一直有着三分技术七分管理的说法，因此，审计作为安全管理体系有效性的验证手段，一直是关键的安全有效性验证方案之一。安全管理体系遵循着自上而下的建设模式，先有关于安全战略的顶层设计和领导层支持，然后从组织架构的层面上建立责任清晰的安全分工协作机制，通过安全制度的贯彻，落实安全风险的评估和控制措施的建设，在这个环节中，安全技术只是整个安全体系的一部分。对于这个安全机制运作的是否良好，依赖审计的机制，审计对相关风险是否有制度的覆盖，有风险评估的记录，有制度执行的记录，有控制措施的执行记录，进行审核与检查。可以看出审计主要基于对文本的记录审查，部分涉及到系统的配置和基线检查的工具检查，属于形式审查的范畴。

从内部审查到外部第三方审计，随着数字化时代供应链安全风险的增加，第三方审计机构基于ISO27000系列国际标准的审计，也成为企事业单位向第三方证明网络信息安全控制措施有效性的必要措施和手段之一。

在面对数字化和新技术的需求下，业务过程的实时在线，安全风险超越了传统企业安全的边界，静态的、非连续的、形式上的安全审查对安全控制措施的有效性验证存在着严重不足，审计虽然具有重要的价值和意义，但是单纯地依赖传统审计的方法和手段，显然不能满足安全有效性验证的要求。

3、渗透测试，在研发安全难以覆盖的运营阶段作为安全控制有效性验证手段，是常见的验证模式之一。

在信息化时代，信息化系统作为管理系统和业务支撑系统一般采用标准化的商业套件满足办公需求。数字化和互联网时代，作为业务运作核心的作业系统成为公司的核心竞争力，信息系统往往通过企业自主研发的模式实现，为了快速满足业务发布的需求，获得竞争优势，敏捷开发成为主流，在云原生技术体系的背景下，微服务、容器化、DevOps、持续交付成为常态。传统信息化产品厂商，例如微软在产品开发的瀑布模型时代已经建立了SSDLC的软件开发生命周期的安全管理，在需求阶段做了威胁建模，设计阶段做了安全预防测试能力化的集成，开发阶段的白盒、灰盒、黑盒测试，保障产品开发阶段的安全。在面对云原生环境下，随着研发模式的变革，互联网企业也逐渐演变出了DevSecOps的信息化系统安全开发方案，通过开发安全工具的自动化集成实现产品的安全保障。遗憾的是，安全的专业性，以及从成本效益出发，使得从目前来看，要让互联网企业在研发安全过程管理中都具备开发安全团队，以及具备相应的检测和安全能力集成的能力，仍是一件比较奢侈的需求。

缺失信息化系统开发阶段的安全设计和预防能力集成，仅靠系统部署阶段的安全漏洞检测与扫描，显然会带来更多的风险，这也是业界一直提倡安全左移的由来。在系统运营过程中有效性的验证，主流的方式是通过第三方的渗透测试，以及自建或第三方SRC的白帽众测方式。寄希望通过模拟黑客攻击的方式，以攻击方的视角发现相关漏洞，规避风险。

渗透测试依赖于渗透测试方安全技术的能力和挖洞能力，最大的问题是如何保证渗透测试团队能力的稳定性，和能够覆盖所有的系统风险的问题。如果不能解决这两个问题，即使通过了第三方的渗透测试，也不代表系统是安全的，是没有风险的。毕竟，这种成果高度依赖于渗透测试人员能力带来的不确定性和覆盖率。另外，渗透测试作为阶段性的产物，同样存在不可持续性验证的风险，是渗透测试对安全控制有效性验证难以克服的缺陷。

图一、传统安全有效性验证模式

综上所述，目前的安全控制有效性验证手段，存在静态、非连续、单点、非交互、不透明、覆盖率不确定、手工等一系列问题，想要实现安全控制的有效性验证就需要做到动态、连续、关联、交互、透明、全覆盖、自动化的相关要素。

有效性验证是个复杂命题，传统的验证模式并不是没有存在的价值，建立安全基线，对安全配置有效性的验证、检查，基于清单机制的验证、排查，做到静态的验证仍然是必须的。具备研发安全管理能力和相关自动化工具，对漏洞等脆弱性的检查和扫描仍是有效性验证不可或缺的一部分。对制度、流程、记录的形式审查仍是有效的功能验证的必要手段，渗透性测试和SRC下的白帽众测，同样会从不同角度和视野带来具有价值的有效性验证。只不过，我们会在此基础上，更加强调缺失的有效性验证部分，通过对相应能力的补充建设，实现全面的安全控制有效性验证。

1、红蓝对抗，组织级的可持续实战演练有效性验证。

攻防对抗作为安全有效性验证的手段之一，最容易引起关注，涉及到对脆弱性的直接利用，造成安全事件的影响，对于非安全的业务部门和主管单位而言，更加直观。渗透测试从攻击者视角的漏洞挖掘和验证，在业务无损的前提下，实现有限的安全验证一直是常用的攻防手段之一。在攻防演练的背景下，以漏洞的验证和利用，达到攻击和破坏的模拟效果，相对于渗透测试更进一步。相对于国家级和省市级的攻防演练，企业如果具备自己的传统意义上的攻击队——红队，那么可以有组织、持续化地攻防演练，对企业的安全控制有效性验证，势必效果明显。但是，如果红队仍是基于传统的挖洞思维模式，在实验环境进行模拟攻击，就会存在覆盖率的问题，如何验证红队的攻防演练是否覆盖到了应用系统可利用的漏洞，这是一个挑战。

MITRE发起的ATT&CK项目，从攻击者的角度，对攻击者战术、技术、流程进行细化，形成TTP的图谱，涵盖了已知攻击者视角的攻击路径分析和全量攻击图谱，其中的开放性为图谱的更新和完善的及时性奠定了基础，是企事业网络信息安全防御体系建设不可或缺的重要参照物，红队的作战路线图和计划，可以参照建设。攻击者在防守者安全防御和保障体系的建设中，也已经脱离了传统脚本小子和单兵作战的阶段，全面进入了有组织的体系化攻击时代。目前，各国安全公司和情报组织发现了近百家高级可持续威胁（APT）组织，而且各组织的攻击TTP（战术、技术、流程）具有鲜明的个性化特征，从漏洞的利用，武器的构建，攻击的模式上，具有明显的可识别性。这也促生了对APT组织的TTP映射到ATT&CK中，实现ATT&CK中ATP组织攻击向量的重建。

蓝军构建网络信息安全体系时，基于数据驱动的安全，实现对攻击的发现，预警一直是甲乙双方梦寐以求的理想。早年的SOC建设，后续基于日志与流量的SIEM建设，包括当下热点的XDR建设，无不希望在企业中发现攻击者的身影，实现预警、溯源甚至反制。但建立关联分析始终是一个难以逾越的门槛，无论是基于经验的规则，还是基于人工智能深度学习、机器学习的无监督算法，如何实现大海捞针真是个技术活，解决不了误报的问题，就会与早年IDS、IDP、下场类似，食之无味、丢之可惜。而基于ATT&CK对APT组织的攻击向量重建形成的威胁狩猎（TH）似乎是看到了一点曙光。

破坏与攻击模拟（BAS）技术，在2021年Gartner的网络安全运营技术炒作曲线中达到了技术炒作的顶峰，只不过距离成熟度仍有6-8年的周期。最新的2022年的技术曲线中，成熟度周期已经缩短，可见该领域的投入以及发展迅速。突破传统的单点漏洞利用和验证，在企业真实的信息化部署场景中，通过对资产漏洞的发现，实现多漏洞的组合利用，形成攻击的模拟，进而实现真实的突破和对安全控制的有效性验证，确实对企业安全体系建设来说具有重要意义。当然，需要突破的难点仍然非常多，存在巨大的挑战。

2、扩展的攻击面管理，实现自动化持续化红军，是全面验证控制有效性的未来。

本年度攻防演练的第一周，相对于以往的0day频出，明显呈现出不同的特征出来。首先，社会工程明显增多，这不得不让我们想起第一黑客麦克尼利，并不一定需要多高深的技术，有时候仅是利用人性的弱点。这也给我们上了生动的一课：安全意识教育不仅是标语、口号，而是实实在在的防线。而NG、Log4J这两个貌似顶级的0DAY漏洞在引爆之后，据安全企业的验证，可能是惑敌的烟幕弹，也是促使防守方自乱阵脚的秘密武器，攻防演练的舆论战，已经不知不觉地来到我们身边。

Gartner在2021年网络安全运营炒作技术曲线中提到了两个新的概念，一个是扩展的攻击面管理（EASM），一个是比较拗口的自主的可持续化的红队，我觉得firecompass基于此提出的产品理念自动化可持续红队（CART）更贴切和容易记忆，因此，本文就针对这两个方向稍微做下延伸和联想。

攻击面管理（ASM）已经是一个耳熟能详的概念，但显然更多的从业者关注的是企业的攻击面，甚至是企业边界的攻击面。美国针对企业的网络安全产品，一般是定义到办公网的范畴，关注的是员工、终端、办公内网的安全体系建设，甚至对IDC涉及有限。毕竟美国大部分企业的信息化体系建设成熟，近年的发展也逐渐迁移到公有云设施之上，所处的环境与中国企业有较大的差异。从互联网和数字化的角度而言，中国在弯道超车的同时，也暴露了信息化和数字化基础设施建设的短板，照抄美国的网络信息安全防御机制，会暴露出大问题。因为，中国的企业不能按照美国企业一样关注点仅放在办公网的安全。

中国企业需要关注自己的业务承载，甚至2C业务系统环境下整个企业的安全边界，也即生产网的安全。随着软件定义边界（SDP）等零信任概念的普及，中国企业已经逐渐意识到生产网和办公网之间的连通性，不存在所谓的内网和边界，在关注南北向的同时，需要把视角进一步延伸到东西向的内部。一个重要的信号是，企业对网络资产的发现、管理，不能仅停留在主机、设备、IP、中间件层面上，而需要关注到开源组件、软件工程、数据等新兴的资产上来。

即使在美国，Gartner提出的EASM8个用例中，同样对资产的丰富性，组织的丰富性，分支机构、收购以及企业生态的复杂性、供应链、合作伙伴纳入到扩展的攻击面管理中。相对于国外调研机构的数据泄漏事件主要出自内部的观点，据我们的实证研究，中国的数据泄漏主要源自于合作伙伴。相对于传统的信息化管理系统，业务系统的生态关联性更强，特别是平台型企业，链接生态环境中的复杂性，导致企业的风险来自于四面八方。因此，合作伙伴的扩展攻击面管理刻不容缓。

红队的建设从无到有是攻防演练不可淹没的功劳，但长久维持一个人工的红队进行持续性、自助的攻防演练，显然从成本的角度上不太可行。但基于攻击向量的红队持续化的模拟破坏攻击又是不可或缺的安全控制有效性验证手段，自动的、可持续性红队成为一个显而易见的答案，理念容易，实现需要突破现实中的障碍。

智能化、自动化是安全领域蓝军建设应急响应能力的手段之一，XDM扩展的响应与检测可以看做自动化编排（SOAR）与安全信息与事件管理（SIEM）的融合与升级实验，那么威胁狩猎（TH）与SOAR的整合，是不是可以看作是红队智能化和自动化的一种可能路径呢？拭目以待。

时代在变，企业从信息化走向数字化，同样，网络与信息安全的攻防体系建设不能墨守成规，既要为企业数字化建设服务，也要实现网络与信息安全体系的数字化，过程中的跨界整合与创新，需要安全同仁付出不懈的努力。相信，自动化红与蓝对安全控制有效性全面的验证就在不远的未来。

推荐阅读

---

2022诸子笔会  

【7月主题：误区与陷阱】

刘志诚  张永宏  孙瑜  王忠惠  肖文棣  

朱文义  杨文斌  孙琦  陈圣  回顾

【6月主题：远程办公与安全】

王忠惠  于闽东  刘志诚  孙琦  朱文义

  张增斌  肖文棣  杨文斌  张永宏  孙瑜  陈圣 回顾

【5月主题：安全之变】

 王忠惠   张永宏  朱文义  于闽东  刘志诚  杨文斌 

 孙琦  孙瑜  半藏咸鱼  肖文棣  王振东  陈圣  回顾

推荐阅读

---

2021首届诸子笔会

   颁奖 | 评优投票 | 1月盘点 | 12月盘点

11月盘点 | 10月盘点 | 9月盘点 | 8月盘点

7月盘点 | 6月盘点 | 组团 | 报名

戳原文阅读查看往期征文合集

齐心抗疫 与你同在 

你怎么这么好看

岁末年初，总结与规划是两个绕不开的主题，上篇文章谈了业务视角的安全总结如何做，本篇文章仍然围绕着以业务为中心的思路谈如何做安全规划。相对于安全计划明确的目标，清晰的路径，指导具体的实施和执行，规划是要找到目标和路径，确定需要的资源，达成高层与利益相关者的高层共识，指导安全计划的完成。

图一、安全规划三部曲

安全规划的三部曲首先需要清晰完整的找到输入，既包含需求又包含制约因素，其次是要有明确的方法落实规划，最后是业务视角的规划输出，用于高层与利益相关者的沟通和指导安全计划的制定。

清晰完整的输入首先在于规划的需求源自什么，没有输入的规划如无根的浮萍，难以逻辑自洽，自然会受到质疑，因此，首先需要找到规划的起点，即规划的需求来源。安全的规划最直接的来源是风险登记表，从国际认证信息安全风险管理师（ISACA CRISC）的观点来看，风险登记表作为以识别安全风险在企业风险接受度下的动态管控风险的系统，为企业的安全风险建立里全面的概貌，是指导企业信息安全管理的重要工具。因此，首先，安全规划源自于风险登记表中大于企业风险接受度的风险管控措施的落实的集合。

风险登记表源自于风险评估，涉及到风险评估与风险处置的专业领域，在系统变更和年度总结时，会对风险登记表进行更新，以动态的反应企业的风险实践情况，是安全规划最直接的输入。风险分析，评估，处置本身是一个风险从业者和安全从业者基于专业领域再加工的过程，在安全规划环节中，考虑到安全规划涉及到企业利益相关者的共识沟通，需要进一步溯源风险评估的上游输入，使用业务语言描述风险对业务的影响，以及风险措施的必要性分析。

所以，安全规划需要与业务战略保持一致的基础上，引用风险登记表并佐以业务说明，在这个角度上，两个业务相关的评估方法的输出，也是安全规划的必要输入，首先是首席数据官（exin dpo）中的一个方法个人数据影响分析（PIA）借用的业务影响分析（BIA），另外一个是从企业风险管理（ERM）中借用的BCP（业务连续性分析）。PIA作为个人信息保护的重要工具通过对业务中对个人数据从采集，到分析，应用的节点中对业务的影响进行分析，指导数据保护官关注个人数据的业务过程，从而为保护措施的规划，实施，审计提供依据。同样，业务视角的安全影响分析，为业务流程的所有者，提供业务影响的分析，为安全从业者与业务负责人建立统一的语言，对安全规划沟通中达成共识，十分必要。BCP是业务负责人需要关注的全面业务风险，安全对BCP的影响，在BCP的规划和计划中体现，是推动业务负责人建立安全意识，主动驱动和落实安全规划的重要方法。因此，BIA和BCP作为业务视角和业务语言的风险管理前置输入，同样是安全规划符合业务方向和战略规划，在沟通层面形成语言一致，逻辑合理的重要输入。

输入中不能忽视的输入是约束条件，主要包含两个层面，一个是安全内部维度的评估，企业的安全文化，安全意识，安全团队的能力，规模，和现状。另一个是业务战略相关的维度评估，主要涉及业务战略，预算投入，风险接受程度。

这两个个约束是避免安全规划大而不当，不切实际，难以落实。因为，无论是规划难度过大而引起的团队士气低落，成就感不足，还是业务部门和利益相关者对安全工作的满意度不高，管理层对安全工作开展绩效的不满，都会对安全工作的严肃性，权威感造成负面影响。安全工作普遍意义上的理解是合规中心，成本中心，是制约业务发展，影响企业效率的平衡措施，虽然这些理解存在不合理，扭曲，但偏见的形成非一朝一夕，安全从业者对利益相关者的观念扭转需要细水长流，在安全规划节点上，注意制约因素，提前预防，从而避免因规划不当而造成的安全工作开展雪上加霜。

规划的过程不是输入的照搬照抄，而是再加工的分析，分类，问答环节。问题驱动，首先清晰定义问题，解决方案，要给出制约条件下的最佳问题答案，价值提升，解决这个问题的业务价值和意义是什么，说清楚这三件事，是完成安全规划的前半部分，后半部分是把安全当作一个整体，透过具体的问题和方案，抽象总结安全的趋势，安全的价值，安全的宏观视图，抽象和升华到安全对企业的整体价值和影响。

常规的安全规划是直接给出解决方案，甚至是直接的产品和服务的组合，这样的规划沟通起来就会非常费劲，需要上溯到必要性，为什么，专业术语，技术细节乱飞，很难达到有效沟通的效果，往往鸡同鸭讲，不欢而散。而从问题出发，是从业务面对的安全风险带来的问题的实际场景出发，业务面对什么样的安全问题是把BIA、BCP以及风险评估的结果通过业务语言场景化的阐述，清晰定义出要解决的问题。这样，业务部门，和管理层清晰的知道你的目标是什么，沟通起来就更畅快。

解决方案在规划层面不是具体的产品，而是针对这个问题的方案有哪些，2-3个备选方案，包含业界的标杆和团队自主的思考，在这个阶段是没办法给出结论的，但是有明确的解决方案的方向，是需要安全团队去沟通，测试，验证和实施的。在解决方案的环节，多样性和选择性，是业务部门和管理层可以参与意见和提供决策建议的节点，如果是达成共识的决策，对后续安全规划的落实以及指导安全计划的输出同样价值匪浅。

不能忽视的环节是价值提升，解决方案的目的当然是解决安全问题，但在解决安全问题的同时，需要思考这个解决方案带来什么样的价值，这事考量和平衡解决方案选择的重要因素之一，解决一个问题通常会有不同的方案，在业务和合规，效率与安全平衡的节点时也往往有短期方案和长期方案的区别，但从经验来看短期方案往往在解决表面问题后成为长期方案，从而给企业和业务带来长期的风险，后期的治理成本高昂。因此，从业务的角度多思考一步价值提升，能不能为业务带来价值，能不能为企业带来价值。这个价值不能狭隘的从经济利益一个维度思考，在国家高度重视安全的背景下，解决方案的先进性，创新性，在公司的企业形象上，在上市公司的市值管理上，也可能具有重大的公共关系价值。这是安全规划阶段需要考虑的因素之一。

以问题驱动的多选择解决方案关注业务价值提升只是做到了安全规划工作的前半部分，以点和面的思维来解决具体问题。后半部分需要从整体的观点思考全局安全工作，把散落在具体问题和具体解决方案之中的共性，趋势，散落在具体问题和具体解决方案之外的洞察和思考，形成安全对业务从保障到驱动的观点，转换为可以落实的团队，技术体系，管理运营体系的建设策略。既要低头拉车，也要抬头看路，保持团队的先进性和创新性，才能适应高速变化的社会需求，实现安全的从业务保障到业务驱动的飞跃。

规划是过程，输出才是规划的成果，从国际项目管理师（PMP）的角度而言，一个项目要从时间，资源，质量约束下实现目标，借鉴过来，一个好的安全规划输出要包含几个要素，预算表，能力矩阵，路线图。

规划和预算是两个相关但在操作中可能被分离的过程，一个是专业语言，一个是财务语言，但其实在规划中，需要从资源约束的维度思考，输出预算表，在实际操作中，会从存量延续，方案新增，能力提升的维度划分出不同预算的类别，并根据规划的依据确定预算的范围。以规划为依据的预算，在和财务部门和管理层沟通中，会节省彼此不少的时间，是管理效率提升的体现。

能力矩阵是解决方案与能力提升抽象整合的产物，也是企业安全架构的动态版本，通过安全规划在企业安全架构中的位置，从整体上可以关注企业安全风险治理的现状和进展，结合风险登记表和风险视图，在安全风险和安全风险治理的层面上达成利益相关者的共识，推动安全规划的落实具有重要价值。

路线图是时间约束的体现，在能力矩阵的基础上，对关键解决方案和能力提升项目化的给出年度里程碑和关键节点，为后续安全规划落实到可执行的安全计划，在投入，进度环节与管理层和业务部门等利益相关者达成共识，直接关系着安全规划的落地和实施。

最后，不得不提的安全规划的PDCA维度的持续改进，以及安全规划的能力成熟度模型，这也是安全规划和安全总结实现闭环必不可少的环节，只有建立从安全规划到安全总结的闭环，才能实现安全工作的持续改进，达到理想的从业务保障到业务驱动的安全规划状态。