近期参与了一个安全系列内部讨论会，我们会从企业安全的不同层面和阶段进行细粒度的研讨沟通，基于自身的经历思考和我们的研讨内容进行总结和分享，欢迎各位一起来交流沟通。这次我们把主题定为“资产库”。

       资产的梳理是企业安全建设的第一件事，也是最重要的事情，好的安全不能盲人摸象，我们需要把资产梳理清晰，这样才能知道自己的安全建设边界在哪里，工作目标是什么，工作范围是什么，工作重点是什么，出了问题才能有据可查等等。

        开始正题之前，我们先聊下安全的概念，最早国内对安全定义为信息安全（Information security），这里的信息是什么，是数据（data）。随着安全的发展，我们给安全定义为网络安全（Cyber servurity），这里的网络指的是网络空间（cyber-space）领域中的任何事物。安全的目标也由保证数据的安全向保护网络空间领域内的事物安全转变。

附一张信息安全和网络安全的对比：

        当我们了解了网络安全的定义和概念，我们今天要解决的就是安全的对象“网络空间（cyber-space）”在企业中的落地的问题，为了更好的理解和沟通，我引用cissp中的一个词来代替它，就是“资产库”。

       1、什么是“资产”？

       答：把目标放到安全视角，我认为就是企业有价值的东西，可以是有形的，比如服务器、存储介质等，可以是无形的，比如系统、数据等。

       2、什么是“资产库”？

       答：用来记录资产的基本信息，维护了组织拥有的软件硬件资产的准确和及时的状态信息

       3、本次话题的“资产库”的“用户”和“需求方”是谁？

       答：企业安全人员

       4、本次话题的“资产库”的目的和意义是什么？

       答：确定业务安全工作的目标和范畴，是支撑业务安全建设的基础库

       5、本次话题的“资产库”的落地形态是什么样的？

       答：记录企业安全所需数据的一系列平台的总体称谓，不同维度资产对应企业不同平台，如下图：

        配置管理数据库( Configuration Management Database,CMDB)是一个逻辑数据库，包含了配置项全生命周期的信息以及配置项之间的关系(包括物理关系、实时通信关系、非实时通信关系和依赖关系)。（百度百科）

        安全的CMDB相关功能可以满足如下但不止如下要求：

        a)各类资产信息

        服务器信息：主机名、内网IP、外网IP、操作系统、开放端口、责任人、所在区域、是否安装主机防护agent、组件信息、网络开放范围

        网络设备信息：设备名称、IP、责任人、所在区域

        安全设备信息：设备名称、IP、责任人、所在区域

        域名信息：域名地址、开放端口、网络开放范围、是否接入waf

        接口信息：接口地址、请求方式

        网络拓扑：生产网拓扑、办公网拓扑、测试网拓扑

        b)资产信息支持手动录入和接口对接自动更新

        接口对接自动更新部分：如对接各类云平台，云平台上创建，自动同步至cmdb

        c)快速检索

        可以基于ip、端口、组件等信息进行快速检索

        d)报表功能

        可以筛选后以excel等格式导出

        e)系统自身安全

        账号层面支持与公司ldap等对接同步

        支持双因素认证，如googleauth、短信等

        支持权限控制：不同的人员角色，只能看到自己相关信息

        支持操作审计：存在用户登陆平台后的操作审计日志

 

        上述信息如何收集呢？

        1、云上资源直接通过api同步，如主机名、ip、操作系统等机器基础信息

        2、通过商业版主机安全agent识别后，api对接获取，如组件、进程信息

        3、通过nginx日志识别，如接口信息

        4、通过Dnsport获取，如域名信息

        5、通过漏洞扫描器获取，对现有机器基础信息进行比对、补充完善，如ip、端口、组件

        6、通过手工录入，如网络设备信息、安全设备信息、网络拓扑

        数据库级别的CMDB，我们可以基于字段、表、库等信息快速定位数据库资源、相关业务系统及对应的负责团队。

        相关功能可以满足如下但不止如下要求：

        a)数据源

        数据库（mysql、mongo等）

        数据仓库（hive等）

        b)信息内容

        库信息：集群名、库名、表名、表描述、字段名、字段描述、负责人、所属业务等

        数据分类分级信息：为敏感字段打标签，如绝密、机密、秘密、公开等

        数据库调用记录：应用名称、业务归属、集群名、库名、表名、字段名、责任人

        c)数据变更

        变更审批流程

        变更操作记录

        d)数据权限申请

        数据库权限申请流程：细化至字段级别

        e）系统自身安全

        账号层面支持与公司ldap等对接同步

        支持双因素认证，如googleauth、短信等

        支持权限控制：不同的人员角色，只能看到自己相关信息

        支持操作审计：存在用户登陆平台后的操作审计日志

 

        数据地图平台在各公司一般由DBA、大数据团队、BI团队设计开发，安全是很少一部分的需求放，所以详细技术部分略过，不细讲了。简单聊聊上述平台对安全的意义？

        1、此平台是公司数据治理、数据安全的强有力基础支撑，能更好的落地公司数据标准化、数据分类分级等要求；

        2、数据申请流程标准化，降低公司内部沟通成本；

        3、数据查询统一化，统一管理，统一审查；

        4、出现信息泄漏等问题，可以通过平台快速定位库的范围

        主机、网络设备、安全设备、应用系统等的日志统一收集、管理、分析平台。典型平台如：splunk、elk、ossim。

        相关功能可以满足如下但不止如下要求：

        a)日志聚合功能

        b)数据索引

        c)搜索功能

        d)日志提取功能

        e)可视化功能

        f)电子邮件提醒功能

        g)系统自身安全

        账号层面支持与公司ldap等对接同步

        支持双因素认证，如googleauth、短信等

        支持权限控制：不同的人员角色，只能看到自己相关信息

        支持操作审计：存在用户登陆平台后的操作审计日志

 

        日志分析管理平台的核心价值：        

        1、日志独立集中存储，规避机器本地日志丢失后产生的风险

        2、很多设备自身的日志查询检索速度较慢，专业的日志分析平台能较大提高日志检索分析效率

        3、可以进行日志关联分析，降低独立登陆多个平台离散分析的时间成本

        1、数据泄漏场景

        当安全团队发现“暗网”存在贩卖公司数据时，可以通过某些手段获取到贩卖的公司数据的部分信息，基于字段在“数据地图平台”上快速定位是公司哪个业务团队、哪些库可能出现问题，通过统一修改库账号、虚拟账号等手段快速“止血”，再通过“安全cmdb”和“日志分析管理平台”执行安全应急响应处置工作。

        2、挖坑场景

        2.1、已知漏洞场景

        当公司遇到saltstack或sturct2漏洞攻击时，安全团队可以基于“安全CMDB”快速定位开放4505/4506端口或stuct2组件机器，进而执行相应的修复操作，缩短应急响应时间。

        2.2、未知漏洞场景

        此场景发现成本较高，可以通过主机层面的资源监控、主机安全agent告警、蜜罐告警等方式进行发现公司主机存在挖坑行为，然后通过“日志分析管理平台”上的存储主机日志、安全设备日志，联动查询，缩短应急响应时间。

        任何事物的决策都是一道选择题，不同的选择带来不同的结果。有人愿意做上述集中库或平台的建设，觉得数据集中了，可以更容易做集中管理和标准化；有人抗拒做库或平台的建设，觉得把经历和成本放到了非关键的工作上。我认为两种选择都没有对错之分，不同的场景会有不同的抉择，鞋舒不舒服只有脚舒服。

        上述内容只是自己在一段时间内容个人总结，可能有很多不足的地方，仅供参考，欢迎交流，后续自己也会持续维护更新。

 

 

参考链接：