“ 今年，安全运营工作推进的过程中又遇到了新的问题，主要是安全度量和自动化两个方面，均对基础的资产数据有非常强的依赖。故今年重新思考新环境下的安全资产管理问题。文章如往常一样分四个问题，一、背景，二、目标，三、架构，四、实践。坚持实践我的思考框架，以基因和驱动为思考的起点，明确目标，顶层设计，坚持实践出真知。”
聊事情，先找驱动力。就像查案，先找动机一个道理。没有强大的驱动力，咫尺和天涯没有区别。
一）资产管理耽误了谁
只有痛苦和渴望，才能驱动变革。1、 当下的痛点（问题）
认知不全、视野不全、保护不全。场景1：安全负责人之痛有多少需要保护的资产（基数），已有保护措施是否到位（覆盖率），已有保护措施是否有效（有效性）。度量需要的基础数据不全，无法数字化、可视化，如何向领导汇报说明防护体系能不能行？。场景2：运营负责人之痛领导要求数字化结果如何提供，指标设计完成后发现基础数据收集不到、收集不准？日常运营、应急响应等工单，明明有自动化系统、明明可以自动化，却因为各部分资产数据孤立而无法自动化？想了解研发、运维领域的安全运营情况，发现基础数据获取需要大量人工的沟通、协调、统计等？场景3：运营执行人之痛运营工作需求处理大量的工单，因为各团队资产数据孤立、不全、不准，大部分时间损耗在沟通协调上，带来大量的简单重复的查询、复制、粘贴、确认工作。导致人员价值无法发挥，无时间进行安全研究，导致人员能力无进步，离职等等问题。场景4：应急响应人之痛威胁情报无限清晰，哪受影响无限迷茫，哪台主机有？是哪个版本？告警IP清晰明确，资产是谁的搞不清楚？入侵行为清晰明确，能不能关搞不清楚？资产信息无法及时获取和确认，导致应急响应工作开展过程 困难重重。
2、未来的绸缪（需求）
1）管理需求之精细化
信息安全重建设阶段慢慢成为过去，越来越多的企业重视安全运营。需要更精细化的管理手段，也意味着需要更多的基础数据支撑。提前准备精细化管理需要的基础数据已为时不早。
2）基础架构之云原生
IT的基础架构正在面临重大变革，对安全团队而言如果不换思想，可能就要面临换人。在硬件和虚拟化时间存在的问题，需要提前布局资产管理的措施，不要让问题再次重现。同时原生的适应云环境也是资产管理必做的功课。
3）研发安全之DevOps
随着研发体系向DevOps转型，原有的研发安全能力必须能够支持DevOps，安全能力需要更高的自动化能力，需要汇总各个检测工作检测结果，作为基础数据进行综合判断。研发安全未来也需要运营指标，需要基础数据展示每个应用的画像，最终实现可以直观的判断应用系统的安全现状和趋势。
二）安全资产是什么
叫什么不重要，人工定义是什么也没有意义？我喜欢的定义方式，有什么用就是什么？所以安全资产：能为安全管理、运营工作提供支撑的基础数据。IT资产管理（ITAM）：为支持IT管理工作。安全资产：为支撑安全建设、安全运营所需要掌握的资产数据库。安全资产管理：为信息安全建设、运营提供支撑的资产数据管理工作。
1、ITAM VS CMDB VS 安全资产 的区别
通过需求目标、需求场景、数据深度、使用场景进行对比。由于建设时的需求和目标不同（基因），各个资产管理系统对资产范围的广度、深入，收集和使用的场景均有很大的差异。 ITAM CMDB 安全资产管理需求目标 IT资产管理支撑 运维配置管理 信息安全运营支撑需求场景 IT资产价值统计 DevOps&自动化 度量、排查、应急数据深度 硬件、软件 配置等 进程、服务、端口使用场景 SN、使用人 IP等 版本、漏洞
三）安全资产范围在哪里
根据安全场景选择资产的动态接入。基于需求选择范围和深度。机房资产、办公资产、私有云、公有云等。详细列表在xmind中，如有共同需求可共同探讨。
四）安全资产管理挑战
- 跨团队收集资产信息，仅是技术难题？
- 资产数据源标准不一，对接自动化困难。
- 资产定时更新、触发更新如何选择？
- 资产信息准确性，谁来保障，如何保障？
- 资产收集后是否留存，不留存怎么查，留存怎么更新？
- 安全资产的数据源和数据量巨大，维护成本怎么算？
- 安全建设、运营场景众多，如果保障资产数据可以灵活支持。
