面向安全的智能资产中心实践之路 - 嘶吼 RoarTalk – 回归最本质的信息安全,互联网安全新媒体,4hou.com

面向安全的智能资产中心实践之路

bt0sea 技术 2021-04-20 11:00:00
收藏

导语:资产管理模块优劣取决于资产采集展示的及时性和准确性,以及与安全产品良好的匹配度。

一、资产中心需求

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

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

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

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

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

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

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

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

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

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

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

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

@3、...

二、资产中心演进历史ITAM4

ITAM4.png

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

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

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

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

三、资产中心详细设计

3.1 资产中心整体架构

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

ITAM1.pngITAM1

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

ITAM2ITAM2.png

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

第三层,资产可视化

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、资产大屏

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

ITAM5ITAM5.png

3.2资产中心详细设计

ITAM3ITAM3.png

技术选型与要求:

@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 原创稿件,授权嘶吼独家发布,如若转载,请注明原文地址
  • 分享至
取消

感谢您的支持,我会继续努力的!

扫码支持

打开微信扫一扫后点击右上角即可分享哟

发表评论