一、资产中心需求

“请各位HW服务方提供一下目前安装的系统java组件名称以及版本号、以及这些组件的是否存在安全漏洞”，这是护网场景中，高频安全业务需求，相信很多护网小伙伴都会碰到过，具体的处理流程，找业务系统开发商提供，开发商需要手工登陆到每台机器上去找对应的软件和版本，通过Excel报表提供HW安全运营人员，安全运营人员通过漏洞扫描结果对比，形成一张总表，提供给用户。

从上面的例子我们可以看出资产管理对安全能力输出很重要。站在攻击视角回头审视我们当下的资产管理，我们提出了更高的设计要求：

· 资产采集展示的及时性和准确性

· 资产管理与安全产品良好的匹配度

先说明一下，本文讨论范畴仅限于服务器资产。

第一步：固定资产管理系统在资产录入，分配资产归属后，系统需要快速发送变更消息给SOC资产管理模块，才能做到及时发现。传统的固定资产管理系统没有消息变更处理模块，这样SOC资产管理块就需要在短时间内定时同步，伴随着资产规模的增大，同步时间也会过长，导致资产变更准确性降低。

第二步：发现物理服务器入库后，或者云主机购买后，需要提示SOC资产管理模块安装主机安全探针，通过探针才能采集到更详细的软硬件清单、虚拟资产清单，同时也能感知到以上清单变更的消息。这个过程有可能需要人工介入，所以，公司的安全部门一般通过EDR覆盖率指标来考核效果。

第三步：通过以上两步资产采集能做到及时性和准确性，还需要对应的资产部署安全防护措施，针对域名需要部署WAF、针对IP地址或者负载均衡需要部署物理防火墙或者云防火墙、针对数据库需要部署数据库审计等，所以通过WAF覆盖率、SSL证书覆盖率、防火墙覆盖率、数据库审计覆盖率、堡垒机覆盖率。

第四步：拥有了精准的资产以及安全设备、就可以关联告警、漏洞、基线到资产，有效地以安全视角对当前主机资产进行全面监控。当然后续还有自动化处置SOAR等形成安全事件处置的闭环，这些不在本文讨论范围之内。

同时在以下场景中，资产管理模块也发挥巨大作用：

@1、在爆发高危漏洞时，如果安全人员无法确定有哪些资产受到该漏洞的影响，也是头疼的事情，需要通过智能资产指纹查询模块发现影响范围，并且提交漏洞工单，督促相关运维人员完成。

@2、“重保”工作的驱动，重保期间，针对业务系统存在的第三方组件查询，资产信息汇总分析，提出更高的要求。

@3、...

二、资产中心演进历史

通过资产中心发展趋势看，其需要具备以下特性：

1、下一代资产中心需要集成到安全运营中心，使其丰富安全属性，增加数字化资产安全运营价值

2、资产中心需要提供监管机构合规需求，具备根据公司规定设置资产管理规则，缓解数字化资产安全治理压力，例如：SOC2认证、SOX、HIPAA...

3、兼容新兴技术异构平台与环境，例如：K8S、容器、云主机、物理服务器、多云管理等。

三、资产中心详细设计

3.1 资产中心整体架构

下一代资产中心，可分为三个层面实现，根据ITIL规定，第一层，需要获取资产详情，形成CMDB数据库，并且拥有主动和被动资产发现工具、状态更新工具。第二层完成资产存储和分析的工作，根据安全业务需求可灵活制定查询；根据公司政策制定资产准入机制、资产授权机制，满足合规要求。第三层为资产可视化层，在安全运营闭环过程中，提升安全运营人员工作效率，包括：资产合规报表导出、快速定制复杂查询条件（包括基于时间轴查询）等。

第一层，首先要明确资产定义，传统资产定义主要集中找硬件清单、软件清点，那么在政务专有云大规模应用的现在，虚拟化资产清单也是需要考虑一项；2020年以后，有一些前卫大企业用户也在多云场景、构建容器专有云平台做一些尝试，也需要考虑，保持资产管理与时俱进。

第二层，存储与分析主要是为可视化提供存储和分析的能力，通过开源中间件数据库实现。

第三层，资产可视化

1、资产中心仪表盘

@1、安全产品覆盖率，至少包含以下：

安全评分，其中覆盖率影响最终的安全状态。EDR覆盖率，WAF覆盖率，SSL证书覆盖率，数据库审计覆盖率，防火墙覆盖率

@2、与告警、漏洞、基线关联展示

@3、合规报表，SOC 2, HIPAA, PCI DSS, NIST CSF ,CIS

其实就是根据以下标准，厂商通过自己CMDB数据分析产生的解读。

SOC 2 Security:https://www.aicpa.org/content/dam/aicpa/interestareas/frc/assuranceadvisoryservices/downloadabledocuments/trust-services-criteria.pdf

HIPAA:https://www.hhs.gov/hipaa/for-professionals/index.html

PCI-DSS:https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf

NIST CSF:https://www.nist.gov/cyberframework/framework

CIS:https://www.cisecurity.org/controls/

2、资产大屏

需要通过图分析计算展示出核心资产关联关系。

3.2资产中心详细设计

技术选型与要求：

@1、资产数据需要存储在高性能结构化数据库中，ClickHouse是我们最佳的选择，（相比较MYSQL、PGSQL）

@2、变更数据通过elastic search存储，当存在资产变更时，写入结构化数据库中，同时保留状态变更信息。

@3、对外提供Restful API支持，方便其他系统调用。特别是安全运营中心。

@4、定时全量资产同步模块支持分布式任务。变更任务监控kafka消息。

@5、通过主机安全Agent上报主机资产状态。软件变更通过kafka消息上报。

数据库结构与API接口需要根据实际的运行环境设计，就不在这里讨论了。

四、ROI评估

其实在日常安全运营过程中碰到的资产不准确，资产变更无法有效监控相关问题，才让我们重新审视自己的SOC资产管理模块，最开始的设计就很最简单，海量的告警数据（每天百万级别）涌入频繁请求IaaS资产管理API，完成资产补齐的工作，发现没有变更通知，第二次提升精准性，是获取IaaS的计费系统，因为计费系统是通过kafka消息通知的，完成云主机创建、销毁；弹性IP创建与撤销等，我们才具备ms级别的资产变更同步能力，第三次提升，当我们做完全量日志分析、同步固定资产管理系统，重构资产中心模块系统的时候，复用全量日志分析模块，提升了ROI。但是如果你的企业从头做SOC资产中心模块，这个ROI需要谨慎评估，毕竟老板们还是要短期内有产出的。

本文为 bt0sea 原创稿件，授权嘶吼独家发布，如若转载，请注明原文地址