之前一直想分享一些做安全产品的经验，但是很多经验是细枝末节的或原则性、交互性的，单独写出来不成体系，最近拜读完蚂蚁安全团队写的《数字银行安全体系构建》，读到介绍蚂蚁内部各类安全平台建设的时候（安全运营中心、安全大数据平台、安全自动化平台等），结合自己过去经常调研国外安全产品、分析产品设计的经验，一些安全产品的设计思路不谋而合、深有感触，故总结分享出来。当然，国内也有些安全产品已经是遵循这些思路进行设计的了
一、数据与策略分离结构
数据与策略分离架构多见于对抗分析类产品中，如NDR、EDR、CWPP、CSPM等产品中。说起来其实比较简单，其核心含义是：
将安全产品收集而来的数据（流量数据、进程行为数据、文件操作数据、资产数据等），集中存放在某个地方（数据库、数据仓、数据湖等叫法不一），通过预定义（或自定义）的策略，去查询匹配数据，进而得出告警。
目前基本成为国外各类安全产品的通用设计方法，如PA的云安全产品Prisma cloud，通过自定义RQL语言，查询各类云上的Resource Data，得出入侵告警或云资源风险，如下
同时Prisma cloud产品默认支持检查的风险类型、入侵告警类型等，全部都是通过RQL方式统一编写，与用户自定义编写的RQL相同，当然也支持各种联合查询等复杂语法。
再如17年RSAC创新沙盒冠军，资产风险管理类产品的Axonius，通过图形化的交互方式代替了QL（底层还是转成QL的形式），供用户编写规则，规则匹配来发现风险资产，同样内置规则与自定义规则的创建形式完全一样。
值得一提的Axonius自身更像一个资产管理工具，近两年才把CVE识别作为默认能力加上，在之前几乎完全就是资产数据库+高级交互筛选，如果需要发现漏洞，需要通过添加漏扫适配器，添加漏扫任务。但Axonius胜在适配器种类非常丰富（上百种）、资产数据字段非常细致、高级交互规则非常强大，以至用户可在上面构建各类高级查询，来满足自己对资产风险管理的任何要求。
讲到这里大家可能认为，不就是规则能力么？内置规则和自定义规则，哪个产品没有呢？值得一提吗？诚然，规则能力是国内大多数安全产品具备的，但是这其中有几个我理解的核心区别：
1.全量数据存储
数据与策略分离的架构，要求行为数据、流量数据、资产数据等做到全量存储，正常的、异常的均存储下来，供后续通过QL规则查询形成告警。
但是我们常见的WAF、EDR等产品，常规设计是只存储告警数据或与告警相关的数据，这种设计有诸多好处，如不用考虑大数据存储问题、查询问题，性能损耗较少，架构较为简洁等，但是也有明显的安全能力问题，如无法做数据的深度挖掘，上下文关联分析最多只能做短时（因为不存全量数据就只能流式实时匹配，流式处理难以处理长上下文），无法做威胁狩猎，发现规则有问题后只能向后生效，无法向前回溯等
2.事中策略与事后策略
事中的实时匹配策略，我理解跟我们常说的规则很像，由于流式实时处理的技术性能要求、内存要求高，因此实时匹配的策略一般会设计成单条数据的匹配模式，部分安全产品可以做短时或简单的上下文匹配模式，多数安全产品的规则能力实际上设计的是事中策略，止步于此。
区别在于事后策略，由于存储的是全量数据，事后策略可以理解成一个数据挖掘过程，在安全领域比较切当的名词是威胁狩猎，事后策略可以设计的较为复杂，例如PA Prisma cloud产品有自己定义的一套QL语法RQL，可进行多种计算、关联、取位等复杂查询操作，亦或是如Axonius的图形化可交互编写高级查询条件的模式。
事后策略承担的作用是高级威胁的挖掘或补救兜底，如长上下文关联、基于某个计算结果的关联、错误规则（误报、漏报）的事后补救、定期的高级调查、事后的全链路追溯等等，事后策略在安全产品中的体现模式常常以调查模块、威胁狩猎模块等方式出现，一般有部分内置的场景规则，如某某勒索病毒特征组成的关联规则，并且根据最新发现的热点更新场景，也允许用户自定义关联规则，形成场景模型。
因此事中策略负责实时、单条、少上下文匹配，亦或是白名单策略匹配；事后策略负责异步、长上下文、深度数据挖掘，并无优劣之分，但需各司其职。
二、原子能力与执行流的结构
原子能力与执行流的结构，贯彻最彻底的是SOAR类产品，通过接入多安全产品，剧本能力将各个安全产品的处置能力灵活编排，形成执行流。实际不仅仅是应用在SOAR类产品中，各类安全产品都可遵循此思路进行设计，其核心理念是：
将产品的安全能力拆分到一定的颗粒度，形成某种原子安全能力，再通过编排剧本编排这些原子能力，形成一个个执行流，进而形成平台上的某类任务
这种设计思路也在国外新兴的安全产品中得到广泛应用，描述比较抽象，我们来看看案例，Axonius产品的执行中心模块，上文中提到Axonius支持对接上百种安全产品，它进一步把这些安全产品分成安全能力，一个产品拆分多个原子能力
分割好原子能力后，通过编排能力，将这些原子能力编排到一个执行流中，形成一个任务，通过这种模式，形成系统内置任务、用户自定义任务，可灵活设置各种任务
举个比较具体的例子，资产扫描类产品，其原子能力可拆分为：资产发现、资产探活、资产端口识别、资产指纹识别、资产风险扫描，当然还可以拆的更细，风险扫描还可以按各种风险类型拆开如弱口令扫描、CVE版本比对、WEB漏洞扫描等。
用户可根据自己的需求，自由组合这些能力，例如希望监测新上线服务的弱口令漏洞，那么可以组合资产发现、资产端口识别、资产指纹识别、弱口令扫描几个能力，编排组成一个“新增资产弱口令专项扫描任务”。当然，完全实现原子能力与执行流架构还有一些细节，如原子能力输出的数据提取，各个原子能力的输入数据定义等，这里就不展开说明。
最后谈一下这类架构的好处，其主要还是在于高度自定义，除SOAR外，国内很多产品还是内置执行流（或者叫任务类型）模式，不知道大家做产品有没有碰到这类情况，系统内置的任务种类永远不够用，不同用户有不同的想法，最终产品上任务类型就越做越多，冗余且繁杂，并且某些任务之间可能只有一两个步骤的差别，但是从产品层面需要变成一类独立的任务，同时复杂任务的Debug链条非常长，后续的维护成本异常高。
参照原子能力与执行流架构去构建，产品层面需要保证的只是原子能力的拆分合理性和编排能力的灵活性，同时将常见执行流内置为系统内置任务，用户的个性化需求可编排自己的任务类型，每个任务Debug时只需关注在哪个原子能力上出现的问题即可，在不提高用户使用成本的同时，可极大降低个性化需求满足的成本、后期运维成本等。
三、集成性平台的插件化结构
插件化这个词其实大家都很熟悉了，多出现在漏扫产品中，如漏洞POC插件。本节想介绍的并不是这类插件，而是针对多引擎、多产品对接的集成性平台的插件化结构，这类平台如SIEM、SOC、SOAR、CAASM、VM（漏洞管理）等，因此我们先来讨论下这类产品当下的状态。
笔者理解的插件化架构可能和国内的集成性平台的理解并不一样，以漏洞管理平台举例，我们去介绍漏洞管理平台能力的时候可能会这么说
我们支持对接xxx、xxx漏洞源、支持对接xxx、xxx等漏扫引擎、支持对接xxx、xxx等漏洞情报，支持将漏洞同步到xxx、xxx这些BUG或者工单平台上，漏洞处置流程支持在平台上自定义等等
有些产品就把这类叫做漏洞源插件、漏扫引擎插件、情报插件等。笔者认为这还不完全属于插件化架构，插件化架构的核心在于“能否让用户自行编写插件，上传到平台，让平台可对接xxx产品”，需要厂商研发介入对接的情况并不能叫插件化，只能说成平台支持广泛的第三方产品对接。
同样我们看一下具体的案例，OpenCTI是款国外的威胁情报类产品，由于威胁情报平台需要对接多个情报源，因此它也可以定义为集成性的平台，OpenCTI对情报的输入、输出部分，实现插件化架构。
Connector便是OpenCTI的插件，OpenCTI提供了一个python库，包含连接、认证、接收情报、情报处理、已有情报筛选等能力，供用户去自行编写一个Connector，用户可以在这个Connector中实现一个全新的情报源插件或情报推送插件。
然后将符合格式要求的Connector上传到平台上，run起来后，平台便多了一个新产品的对接能力。通过这种方式，OpenCTI在社区中具备了上百个插件，支持数百个情报源对接，并且很多插件都是社区贡献，并不需要动用自己的研发人力。
实际上OpenCTI主要是情报数据的插件化，数据层面的插件化相对比较好实现，比较难实现的是任务层面的插件化，即我们常说的某某引擎对接。引擎插件化的难点在于任务和数据的标准化要同时做，笔者自画的架构图如下（仅供参考）：
集成性平台需先构建自己的标准化任务，包含任务入参、任务结果、任务状态、任务操作等，在平台上完成任务标准化后，通过引擎插件将标准化任务字段转化为引擎的接口字段然后去调用引擎。通过不同的插件，把标准化任务字段处理成各个引擎独特的任务调用字段，从而实现引擎任务插件化。在任务插件化的过程中，需要兼顾数据标准化，主要是对引擎的输出结果标准化，如漏扫引擎的扫描结果，涉及到平台漏洞类型标准化、漏洞字段标准化、漏洞标识标准化等。
这类架构的好处也是显而易见，支持更高的扩展性，更少的对接成本，高度的自定义。如果你在做产品过程中，经常处理产品对接工作，经常因为对方产品接口变动而不得不迭代自己的产品，不妨尝试下插件化架构。
四、图式结构的广泛应用
图式结构在目前的安全产品中应用广泛，不管在国内还是国外安全产品中都被发扬光大，因此这部分仅简单谈谈笔者的理解。
图形化结构天然在描述路径、路径检索等工作中有优势，能够比较直观的展示节点之间的关系，常见的使用案例如攻击路径、代码数据流、数据调用路径、网络/主机访问关系等，因此在对抗类产品、代码安全类产品、数据安全类产品中都得到了广泛支持。
图式结构另一个不易被发现的优势是其描述异构对象的能力，我们常见的表格类设计，就是便于描述同类对象，因为一个表中要求对象字段相同，属性固定，关系类型有限，但是如果需要描述不同对象及其关系，不同对象的属性不同、字段不同，关系类型不同、关系范围多对多，在这种模式下图是最好的选择，同时因为网络安全事件天然就是包含多对象多关系，因此图在安全产品中得到广泛应用。
一个典型的例子就是威胁情报STIX标准，从整体标准层面都遵循图形化结构，如下
从情报层面各个情报类型被认定为图上的节点，不同情报类型字段不同，因此是异构的对象作为节点，节点间的连线作为情报关系，从STIX1.0开始就使用图形化模式构建威胁情报的标准，好处在于更新到STIX2.1，整体标准更新的实际是节点类型（情报类型划分）和连线类型（关系类型），同时增加了分组（各个Domain），整体的标准架构并未发生改动，描述威胁情报的方式也并无大的区别，保持了标准架构层面的稳定性。
五、总结
行文至此，其实最终只是讲的只是一个事情，就是模块化、可扩展、弹性的设计思路，将这个思路映射到安全产品中，映射到具体的某个功能模块的设计中，只是道与术的区别而已，希望以上对在安全产品岗位工作的同学有所帮助。
